diff mbox series

[PACH,RFC] Pass -m -jN to gcc_build from gcc_release

Message ID alpine.LSU.2.20.1801220934360.32271@zhemvz.fhfr.qr
State New
Headers show
Series [PACH,RFC] Pass -m -jN to gcc_build from gcc_release | expand

Commit Message

Richard Biener Jan. 22, 2018, 8:37 a.m. UTC
Currently gcc_release builds GCC (for generating in-tree generated
files) serially - that's prohibitly expensive and takges ages (>4h for 
me).  I'm using (when I remember to edit gcc_release ...) -j6 without
a problem for some years, thus the following proposal.

Any recommendation for the default N?  4 might work just fine as well
and no release manager should do without at least 4 cores...

Thanks,
Richard.

2018-01-22  Richard Biener  <rguenther@suse.de>

	maintainer-scripts/
	* gcc_release (build_sources): Pass -m "-j1" to gcc_build.

Comments

Jakub Jelinek Jan. 22, 2018, 8:57 a.m. UTC | #1
On Mon, Jan 22, 2018 at 09:37:05AM +0100, Richard Biener wrote:
> 
> Currently gcc_release builds GCC (for generating in-tree generated
> files) serially - that's prohibitly expensive and takges ages (>4h for 
> me).  I'm using (when I remember to edit gcc_release ...) -j6 without
> a problem for some years, thus the following proposal.
> 
> Any recommendation for the default N?  4 might work just fine as well
> and no release manager should do without at least 4 cores...

Perhaps
num_cpus=1
if type -p getconf 2>/dev/null; then
  num_cpus=`getconf _NPROCESSORS_ONLN 2>/dev/null`
  case "$num_cpus" in
    '' | 0* | *[!0-9]*) num_cpus=1;;
  esac
fi

and "-j$num_cpus" ?

> 2018-01-22  Richard Biener  <rguenther@suse.de>
> 
> 	maintainer-scripts/
> 	* gcc_release (build_sources): Pass -m "-j1" to gcc_build.
> 
> Index: maintainer-scripts/gcc_release
> ===================================================================
> --- maintainer-scripts/gcc_release	(revision 256939)
> +++ maintainer-scripts/gcc_release	(working copy)
> @@ -210,7 +210,8 @@ EOF
>      inform "Building compiler"
>      OBJECT_DIRECTORY=../objdir
>      contrib/gcc_build -d ${SOURCE_DIRECTORY} -o ${OBJECT_DIRECTORY} \
> -      -c "--enable-generated-files-in-srcdir --disable-multilib" build || \
> +      -c "--enable-generated-files-in-srcdir --disable-multilib" \
> +      -m "-j1" build || \
>        error "Could not rebuild GCC"
>    fi
>  

	Jakub
Jeff Law Jan. 22, 2018, 4:21 p.m. UTC | #2
On 01/22/2018 01:57 AM, Jakub Jelinek wrote:
> On Mon, Jan 22, 2018 at 09:37:05AM +0100, Richard Biener wrote:
>>
>> Currently gcc_release builds GCC (for generating in-tree generated
>> files) serially - that's prohibitly expensive and takges ages (>4h for 
>> me).  I'm using (when I remember to edit gcc_release ...) -j6 without
>> a problem for some years, thus the following proposal.
>>
>> Any recommendation for the default N?  4 might work just fine as well
>> and no release manager should do without at least 4 cores...
> 
> Perhaps
> num_cpus=1
> if type -p getconf 2>/dev/null; then
>   num_cpus=`getconf _NPROCESSORS_ONLN 2>/dev/null`
>   case "$num_cpus" in
>     '' | 0* | *[!0-9]*) num_cpus=1;;
>   esac
> fi
> 
> and "-j$num_cpus" ?
Seems reasonable to me -- I believe we do something similar on our
various internal scripts ({redhat,fedora}-rpm-config).

jeff
Richard Biener Jan. 23, 2018, 10:23 a.m. UTC | #3
On Mon, 22 Jan 2018, Jeff Law wrote:

> On 01/22/2018 01:57 AM, Jakub Jelinek wrote:
> > On Mon, Jan 22, 2018 at 09:37:05AM +0100, Richard Biener wrote:
> >>
> >> Currently gcc_release builds GCC (for generating in-tree generated
> >> files) serially - that's prohibitly expensive and takges ages (>4h for 
> >> me).  I'm using (when I remember to edit gcc_release ...) -j6 without
> >> a problem for some years, thus the following proposal.
> >>
> >> Any recommendation for the default N?  4 might work just fine as well
> >> and no release manager should do without at least 4 cores...
> > 
> > Perhaps
> > num_cpus=1
> > if type -p getconf 2>/dev/null; then
> >   num_cpus=`getconf _NPROCESSORS_ONLN 2>/dev/null`
> >   case "$num_cpus" in
> >     '' | 0* | *[!0-9]*) num_cpus=1;;
> >   esac
> > fi
> > 
> > and "-j$num_cpus" ?
> Seems reasonable to me -- I believe we do something similar on our
> various internal scripts ({redhat,fedora}-rpm-config).
> 
> jeff

Ok, I'll commit the following then if it all goes well when doing
the final GCC 7.3 release.

Richard.

Index: maintainer-scripts/gcc_release
===================================================================
--- maintainer-scripts/gcc_release	(revision 256973)
+++ maintainer-scripts/gcc_release	(working copy)
@@ -209,8 +209,16 @@ EOF
     # on at least one platform.
     inform "Building compiler"
     OBJECT_DIRECTORY=../objdir
+    num_cpus=1
+    if type -p getconf 2>/dev/null; then
+      num_cpus=`getconf _NPROCESSORS_ONLN 2>/dev/null`
+      case "$num_cpus" in
+	'' | 0* | *[!0-9]*) num_cpus=1;;
+      esac
+    fi
     contrib/gcc_build -d ${SOURCE_DIRECTORY} -o ${OBJECT_DIRECTORY} \
-      -c "--enable-generated-files-in-srcdir --disable-multilib" build || \
+      -c "--enable-generated-files-in-srcdir --disable-multilib" \
+      -m "-j$num_cpus" build || \
       error "Could not rebuild GCC"
   fi
diff mbox series

Patch

Index: maintainer-scripts/gcc_release
===================================================================
--- maintainer-scripts/gcc_release	(revision 256939)
+++ maintainer-scripts/gcc_release	(working copy)
@@ -210,7 +210,8 @@  EOF
     inform "Building compiler"
     OBJECT_DIRECTORY=../objdir
     contrib/gcc_build -d ${SOURCE_DIRECTORY} -o ${OBJECT_DIRECTORY} \
-      -c "--enable-generated-files-in-srcdir --disable-multilib" build || \
+      -c "--enable-generated-files-in-srcdir --disable-multilib" \
+      -m "-j1" build || \
       error "Could not rebuild GCC"
   fi