Re: Speedup configure and build with system.h

[Uros Bizjak]

On Mon, Jan 25, 2016 at 2:53 PM, Michael Matz  wrote:
> Hi,
>
> On Mon, 25 Jan 2016, Uros Bizjak wrote:
>
>> This patch caused bootstrap failure on non-c++11 bootstrap compiler
>> [1], e.g. CentOS 5.11.
>>
>> The problem is with std::swap, which was defined in header 
>> until c++11 [2].
>>
>> [1] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69464
>> [2] http://en.cppreference.com/w/cpp/algorithm/swap
>
> Meh.  Can you try the attached patch with a configure test (it includes
> the generated files)?  It works for me with 4.3.4, and should make your
> build include  always.

Yes, this patch works for me and allows bootstrap with gcc-4.1.2 to finish.

Thanks,
Uros.

Re: Speedup configure and build with system.h

[Michael Matz]

Hi,

On Tue, 26 Jan 2016, Uros Bizjak wrote:

> > Meh.  Can you try the attached patch with a configure test (it 
> > includes the generated files)?  It works for me with 4.3.4, and should 
> > make your build include  always.
> 
> Yes, this patch works for me and allows bootstrap with gcc-4.1.2 to 
> finish.

Thanks for checking.  r232836 now.


Ciao,
Michael.

Re: Speedup configure and build with system.h

[Michael Matz]

Hi,

On Mon, 25 Jan 2016, Uros Bizjak wrote:

> This patch caused bootstrap failure on non-c++11 bootstrap compiler
> [1], e.g. CentOS 5.11.
> 
> The problem is with std::swap, which was defined in header 
> until c++11 [2].
> 
> [1] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69464
> [2] http://en.cppreference.com/w/cpp/algorithm/swap

Meh.  Can you try the attached patch with a configure test (it includes 
the generated files)?  It works for me with 4.3.4, and should make your 
build include  always.


Ciao,
Michael.Index: configure.ac
===
--- configure.ac	(revision 232675)
+++ configure.ac	(working copy)
@@ -416,6 +416,15 @@ struct X { typedef long long
 ]], [[X::t x;]])],[],[AC_MSG_ERROR([error verifying int64_t uses long long])])
 fi
 
+AC_CACHE_CHECK(for std::swap in , ac_cv_std_swap_in_utility, [
+AC_COMPILE_IFELSE([AC_LANG_PROGRAM([[
+#include 
+]], [[int a, b; std::swap(a,b);]])],[ac_cv_std_swap_in_utility=yes],[ac_cv_std_swap_in_utility=no])])
+if test $ac_cv_std_swap_in_utility = yes; then
+  AC_DEFINE(HAVE_SWAP_IN_UTILITY, 1,
+  [Define if  defines std::swap.])
+fi
+
 # Check whether compiler is affected by placement new aliasing bug (PR 29286).
 # If the host compiler is affected by the bug, and we build with optimization
 # enabled (which happens e.g. when cross-compiling), the pool allocator may
Index: system.h
===
--- system.h	(revision 232736)
+++ system.h	(working copy)
@@ -217,7 +217,7 @@ extern int errno;
 #endif
 
 #ifdef __cplusplus
-#ifdef INCLUDE_ALGORITHM
+#if defined (INCLUDE_ALGORITHM) || !defined (HAVE_SWAP_IN_UTILITY)
 # include 
 #endif
 # include 
Index: configure
===
--- configure	(revision 232675)
+++ configure	(working copy)
@@ -6534,6 +6534,40 @@ fi
 rm -f core conftest.err conftest.$ac_objext conftest.$ac_ext
 fi
 
+{ $as_echo "$as_me:${as_lineno-$LINENO}: checking for std::swap in " >&5
+$as_echo_n "checking for std::swap in ... " >&6; }
+if test "${ac_cv_std_swap_in_utility+set}" = set; then :
+  $as_echo_n "(cached) " >&6
+else
+
+cat confdefs.h - <<_ACEOF >conftest.$ac_ext
+/* end confdefs.h.  */
+
+#include 
+
+int
+main ()
+{
+int a, b; std::swap(a,b);
+  ;
+  return 0;
+}
+_ACEOF
+if ac_fn_cxx_try_compile "$LINENO"; then :
+  ac_cv_std_swap_in_utility=yes
+else
+  ac_cv_std_swap_in_utility=no
+fi
+rm -f core conftest.err conftest.$ac_objext conftest.$ac_ext
+fi
+{ $as_echo "$as_me:${as_lineno-$LINENO}: result: $ac_cv_std_swap_in_utility" >&5
+$as_echo "$ac_cv_std_swap_in_utility" >&6; }
+if test $ac_cv_std_swap_in_utility = yes; then
+
+$as_echo "#define HAVE_SWAP_IN_UTILITY 1" >>confdefs.h
+
+fi
+
 # Check whether compiler is affected by placement new aliasing bug (PR 29286).
 # If the host compiler is affected by the bug, and we build with optimization
 # enabled (which happens e.g. when cross-compiling), the pool allocator may
@@ -18419,7 +18453,7 @@ else
   lt_dlunknown=0; lt_dlno_uscore=1; lt_dlneed_uscore=2
   lt_status=$lt_dlunknown
   cat > conftest.$ac_ext <<_LT_EOF
-#line 18422 "configure"
+#line 18456 "configure"
 #include "confdefs.h"
 
 #if HAVE_DLFCN_H
@@ -18525,7 +18559,7 @@ else
   lt_dlunknown=0; lt_dlno_uscore=1; lt_dlneed_uscore=2
   lt_status=$lt_dlunknown
   cat > conftest.$ac_ext <<_LT_EOF
-#line 18528 "configure"
+#line 18562 "configure"
 #include "confdefs.h"
 
 #if HAVE_DLFCN_H
Index: config.in
===
--- config.in	(revision 232675)
+++ config.in	(working copy)
@@ -1705,6 +1705,12 @@
 #endif
 
 
+/* Define if  defines std::swap. */
+#ifndef USED_FOR_TARGET
+#undef HAVE_SWAP_IN_UTILITY
+#endif
+
+
 /* Define to 1 if you have the `sysconf' function. */
 #ifndef USED_FOR_TARGET
 #undef HAVE_SYSCONF
@@ -1865,7 +1871,8 @@
 #endif
 
 
-/* Define if your assembler supports .dwsect 0xB */
+/* Define if your assembler supports AIX debug frame section label reference.
+   */
 #ifndef USED_FOR_TARGET
 #undef HAVE_XCOFF_DWARF_EXTRAS
 #endif

Re: Speedup configure and build with system.h

[Michael Matz]

Hi,

On Fri, 22 Jan 2016, Jakub Jelinek wrote:

> > > This may have caused:
> > > 
> > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69434
> > 
> > Guess we need:
> > 
> > 2016-01-22  Jakub Jelinek  
> > 
> > PR bootstrap/69434
> > * genrecog.c: Define INCLUDE_ALGORITHM before including system.h,
> > remove  include.
> 
> Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?

Thanks for the fixup, the problem didn't happen on my system.  This usage 
of sse3 intrinsics inside installed STL headers seems a bit unfortunate 
(not to mention the dubiousness of placing a 180 line function containing 
11 loops nested to level 4 for arcane functionality into a header; but I 
guess this battle is lost with STL).


Ciao,
Michael.

Re: Speedup configure and build with system.h

[Richard Biener]

On Mon, 25 Jan 2016, Michael Matz wrote:

> Hi,
> 
> On Mon, 25 Jan 2016, Uros Bizjak wrote:
> 
> > This patch caused bootstrap failure on non-c++11 bootstrap compiler
> > [1], e.g. CentOS 5.11.
> > 
> > The problem is with std::swap, which was defined in header 
> > until c++11 [2].
> > 
> > [1] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69464
> > [2] http://en.cppreference.com/w/cpp/algorithm/swap
> 
> Meh.  Can you try the attached patch with a configure test (it includes 
> the generated files)?  It works for me with 4.3.4, and should make your 
> build include  always.

Ok with a proper changelog.

Thanks,
Richard.

Re: Speedup configure and build with system.h

[Uros Bizjak]

Hello!

> * system.h (string, algorithm): Include only conditionally.
> (new): Include always under C++.
> * bb-reorder.c (toplevel): Define USES_ALGORITHM.
> * final.c (toplevel): Ditto.
> * ipa-chkp.c (toplevel): Define USES_STRING.
> * genconditions.c (write_header): Make gencondmd.c define
> USES_STRING.
> * mem-stats.h (mem_usage::print_dash_line): Don't use std::string.
>
> * config/aarch64/aarch64.c (toplevel): Define USES_STRING.
> * common/config/aarch64/aarch64-common.c (toplevel): Ditto.

This patch caused bootstrap failure on non-c++11 bootstrap compiler
[1], e.g. CentOS 5.11.

The problem is with std::swap, which was defined in header 
until c++11 [2].

[1] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69464
[2] http://en.cppreference.com/w/cpp/algorithm/swap

Uros.

Re: Speedup configure and build with system.h

[Jakub Jelinek]

On Fri, Jan 22, 2016 at 12:09:43PM -0800, H.J. Lu wrote:
> > * system.h (string, algorithm): Include only conditionally.
> > (new): Include always under C++.
> > * bb-reorder.c (toplevel): Define USES_ALGORITHM.
> > * final.c (toplevel): Ditto.
> > * ipa-chkp.c (toplevel): Define USES_STRING.
> > * genconditions.c (write_header): Make gencondmd.c define
> > USES_STRING.
> > * mem-stats.h (mem_usage::print_dash_line): Don't use std::string.
> >
> 
> This may have caused:
> 
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69434

Guess we need:

2016-01-22  Jakub Jelinek  

PR bootstrap/69434
* genrecog.c: Define INCLUDE_ALGORITHM before including system.h,
remove  include.

--- gcc/genrecog.c.jj   2016-01-04 18:50:33.207491883 +0100
+++ gcc/genrecog.c  2016-01-22 21:21:42.852362294 +0100
@@ -105,6 +105,7 @@
5. Write out C++ code for each function.  */
 
 #include "bconfig.h"
+#define INCLUDE_ALGORITHM
 #include "system.h"
 #include "coretypes.h"
 #include "tm.h"
@@ -112,7 +113,6 @@
 #include "errors.h"
 #include "read-md.h"
 #include "gensupport.h"
-#include 
 
 #undef GENERATOR_FILE
 enum true_rtx_doe {


Jakub

Re: Speedup configure and build with system.h

[H.J. Lu]

On Thu, Jan 21, 2016 at 8:57 AM, Michael Matz  wrote:
> Hi,
>
> this has bothered me for some time.  The gcc configure with stage1 feels
> like taking forever because some of the decl availability tests (checking
> for C function) include system.h, and that, since a while, unconditionally
> includes  and  under C++, and we meanwhile use the C++
> compiler for configure tests (which makes sense).  Now, the difference for
> a debuggable (but not even checking-enabled) cc1plus for a file containing
> just main():
>
> % cat blaeh.cc
> #include 
> #include 
> #include 
> #include 
> int main() {}
> % cc1plus -quiet -ftime-report blaeh.cc
>  TOTAL :   0.12 0.01 0.14
>
> (This is btw. three times as expensive as with 4.8 headers (i.e.
> precompile with g++-4.8 then compile with the same cc1plus as above,
> taking 0.04 seconds; the STL headers bloat quite much over time)
>
> Well, not quite blazing fast but then adding :
>
> % cc1plus -quiet -ftime-report blaeh-string.cc
>  TOTAL :   0.60 0.05 0.66
>
> Meeh.  And adding  on top:
>
> % cc1plus -quiet -ftime-report blaeh-string-alg.cc
>  TOTAL :   1.13 0.09 1.23
>
> So, more than a second for checking if some C-only decl is available, just
> because system.h unconditionally includes mostly useless STL headers.
>
> So, how useless exactly?  A whopping single file of cc1 proper needs
> , _two_ files need , and a single target has an unlucky
> interface in its prototypes and also needs .  (One additional
> header lazily uses std::string for no particular reason).  So we pay about
> 5 minutes build time per stage (there are ~400 libbackend.a files) for
> more or less nothing.
>
> So, let's include those headers only conditionally; I'm pretty sure it's
> not unreasonable for a source file, if it needs a particular STL facility
> to #define USES_abcheader (like one normally would have to #include
> ) before the "system.h" include.
>
> See the patch.  I've grepped for target or language dependencies on other
> STL types, and either they were already including the right header, or
> were covered with the new system.h (i.e. I've built all targets quickly
> for which grepping for 'std::' returned anything).  The genconditions.c
> change is for the benefit of aarch64 as well, and it single function
> aarch64_get_extension_string_for_isa_flags returning a std::string.
>
> What do people think?  Should I pass it through a proper bootstrap and put
> it to trunk?  It's a (developer time) regression, right? ;-)
>
>
> Ciao,
> Michael.
> * system.h (string, algorithm): Include only conditionally.
> (new): Include always under C++.
> * bb-reorder.c (toplevel): Define USES_ALGORITHM.
> * final.c (toplevel): Ditto.
> * ipa-chkp.c (toplevel): Define USES_STRING.
> * genconditions.c (write_header): Make gencondmd.c define
> USES_STRING.
> * mem-stats.h (mem_usage::print_dash_line): Don't use std::string.
>

This may have caused:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69434

H.J.

Re: Speedup configure and build with system.h

[Jakub Jelinek]

On Fri, Jan 22, 2016 at 09:23:48PM +0100, Jakub Jelinek wrote:
> On Fri, Jan 22, 2016 at 12:09:43PM -0800, H.J. Lu wrote:
> > > * system.h (string, algorithm): Include only conditionally.
> > > (new): Include always under C++.
> > > * bb-reorder.c (toplevel): Define USES_ALGORITHM.
> > > * final.c (toplevel): Ditto.
> > > * ipa-chkp.c (toplevel): Define USES_STRING.
> > > * genconditions.c (write_header): Make gencondmd.c define
> > > USES_STRING.
> > > * mem-stats.h (mem_usage::print_dash_line): Don't use std::string.
> > >
> > 
> > This may have caused:
> > 
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69434
> 
> Guess we need:
> 
> 2016-01-22  Jakub Jelinek  
> 
>   PR bootstrap/69434
>   * genrecog.c: Define INCLUDE_ALGORITHM before including system.h,
>   remove  include.

Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?

> --- gcc/genrecog.c.jj 2016-01-04 18:50:33.207491883 +0100
> +++ gcc/genrecog.c2016-01-22 21:21:42.852362294 +0100
> @@ -105,6 +105,7 @@
> 5. Write out C++ code for each function.  */
>  
>  #include "bconfig.h"
> +#define INCLUDE_ALGORITHM
>  #include "system.h"
>  #include "coretypes.h"
>  #include "tm.h"
> @@ -112,7 +113,6 @@
>  #include "errors.h"
>  #include "read-md.h"
>  #include "gensupport.h"
> -#include 
>  
>  #undef GENERATOR_FILE
>  enum true_rtx_doe {

Jakub

Re: Speedup configure and build with system.h

[Oleg Endo]

On Thu, 2016-01-21 at 18:10 +0100, Richard Biener wrote:
> On Thu, Jan 21, 2016 at 5:57 PM, Michael Matz  wrote:
> > Hi,
> > 
> > this has bothered me for some time.  The gcc configure with stage1
> > feels
> > like taking forever because some of the decl availability tests
> > (checking
> > for C function) include system.h, and that, since a while,
> > unconditionally
> > includes  and  under C++, and we meanwhile use
> > the C++
> > compiler for configure tests (which makes sense).  Now, the
> > difference for
> > a debuggable (but not even checking-enabled) cc1plus for a file
> > containing
> > just main():
> > 
> > % cat blaeh.cc
> > #include 
> > #include 
> > #include 
> > #include 
> > int main() {}
> > % cc1plus -quiet -ftime-report blaeh.cc
> >  TOTAL :   0.12 0.01 0.14
> > 
> > (This is btw. three times as expensive as with 4.8 headers (i.e.
> > precompile with g++-4.8 then compile with the same cc1plus as
> > above,
> > taking 0.04 seconds; the STL headers bloat quite much over time)
> > 
> > Well, not quite blazing fast but then adding :
> > 
> > % cc1plus -quiet -ftime-report blaeh-string.cc
> >  TOTAL :   0.60 0.05 0.66
> > 
> > Meeh.  And adding  on top:
> > 
> > % cc1plus -quiet -ftime-report blaeh-string-alg.cc
> >  TOTAL :   1.13 0.09 1.23
> > 
> > So, more than a second for checking if some C-only decl is
> > available, just
> > because system.h unconditionally includes mostly useless STL
> > headers.
> > 
> > So, how useless exactly?  A whopping single file of cc1 proper
> > needs
> > , _two_ files need , and a single target has an
> > unlucky
> > interface in its prototypes and also needs .  (One
> > additional
> > header lazily uses std::string for no particular reason).  So we
> > pay about
> > 5 minutes build time per stage (there are ~400 libbackend.a files)
> > for
> > more or less nothing.
> > 
> > So, let's include those headers only conditionally; I'm pretty sure
> > it's
> > not unreasonable for a source file, if it needs a particular STL
> > facility
> > to #define USES_abcheader (like one normally would have to #include
> > ) before the "system.h" include.
> > 
> > See the patch.  I've grepped for target or language dependencies on
> > other
> > STL types, and either they were already including the right header,
> > or
> > were covered with the new system.h (i.e. I've built all targets
> > quickly
> > for which grepping for 'std::' returned anything).  The
> > genconditions.c
> > change is for the benefit of aarch64 as well, and it single
> > function
> > aarch64_get_extension_string_for_isa_flags returning a std::string.
> > 
> > What do people think?  Should I pass it through a proper bootstrap
> > and put
> > it to trunk?  It's a (developer time) regression, right? ;-)
> 
> Ok.
> 
> Thanks,
> Richard.
> 
> I'm inclined to say #define INCLUDE_ALGORITHM is a better name,
> but just bike-shedding...  and please convert the (bogus) ISL way of
> achieving a similar thing.
> 
> I'm also inclined to say that we should remove  usage.  Not
> sure about algorithm, but I'd say it's the same.
> 

 and  have been put into system.h because there have
been problems with malloc poisoning and C++ stdlib implementation other
than libstdc++, which sometimes pull other headers which then cause
trouble.  The fix for this set of errors was to include some of the
stdlib headers in system.h before anything else.

Cheers,
Oleg

Re: Speedup configure and build with system.h

[Richard Biener]

On January 22, 2016 11:15:38 PM GMT+01:00, Jakub Jelinek  
wrote:
>On Fri, Jan 22, 2016 at 09:23:48PM +0100, Jakub Jelinek wrote:
>> On Fri, Jan 22, 2016 at 12:09:43PM -0800, H.J. Lu wrote:
>> > > * system.h (string, algorithm): Include only
>conditionally.
>> > > (new): Include always under C++.
>> > > * bb-reorder.c (toplevel): Define USES_ALGORITHM.
>> > > * final.c (toplevel): Ditto.
>> > > * ipa-chkp.c (toplevel): Define USES_STRING.
>> > > * genconditions.c (write_header): Make gencondmd.c define
>> > > USES_STRING.
>> > > * mem-stats.h (mem_usage::print_dash_line): Don't use
>std::string.
>> > >
>> > 
>> > This may have caused:
>> > 
>> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69434
>> 
>> Guess we need:
>> 
>> 2016-01-22  Jakub Jelinek  
>> 
>>  PR bootstrap/69434
>>  * genrecog.c: Define INCLUDE_ALGORITHM before including system.h,
>>  remove  include.
>
>Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?

OK.

Richard.

>> --- gcc/genrecog.c.jj2016-01-04 18:50:33.207491883 +0100
>> +++ gcc/genrecog.c   2016-01-22 21:21:42.852362294 +0100
>> @@ -105,6 +105,7 @@
>> 5. Write out C++ code for each function.  */
>>  
>>  #include "bconfig.h"
>> +#define INCLUDE_ALGORITHM
>>  #include "system.h"
>>  #include "coretypes.h"
>>  #include "tm.h"
>> @@ -112,7 +113,6 @@
>>  #include "errors.h"
>>  #include "read-md.h"
>>  #include "gensupport.h"
>> -#include 
>>  
>>  #undef GENERATOR_FILE
>>  enum true_rtx_doe {
>
>   Jakub

Re: Speedup configure and build with system.h

[Michael Matz]

Hi,

On Fri, 22 Jan 2016, Oleg Endo wrote:

>  and  have been put into system.h because there have 
> been problems with malloc poisoning and C++ stdlib implementation other 
> than libstdc++, which sometimes pull other headers which then cause 
> trouble.  The fix for this set of errors was to include some of the 
> stdlib headers in system.h before anything else.

Richard meant to remove use of std::string in the compiler, at which point 
it's not necessary to include  anywhere, in system.h or whereever.

That's a separate discussion, though (I would agree with it).


Ciao,
Michael.

Re: Speedup configure and build with system.h

[Michael Matz]

Hi,

On Thu, 21 Jan 2016, Richard Biener wrote:

> I'm inclined to say #define INCLUDE_ALGORITHM is a better name,

I've done this.  On a different (slower) machine than the one from the 
initial mail:

without patch, -j31 bootstrap all,ada:
real35m2.655s
user395m28.135s
sys 12m10.814s

with patch, -j31 bootstrap all,ada:
real31m45.942s
user364m17.566s
sys 11m1.173s

So, even real-time savings of 3 minutes with a -j31 build; I'll take that 
:)

> and please convert the (bogus) ISL way of achieving a similar thing.

But I've not done this, as I'm not too satisfied with the result.  See 
below; we get rid of the small USES_ISL condition around poisoning 
calloc/strdup, but pay with it for a larger include block in system.h and 
the fact that now any changes to the ISL include list result in a 
recompilation of everything as system.h, not just graphite.h is changed.  
We'd trade a small hack with a larger one for policy reasons.  Let me know 
if you think it's nevertheless better.


Ciao,
Michael.

diff --git a/gcc/graphite-dependences.c b/gcc/graphite-dependences.c
index 0544700..dabc0b9 100644
--- a/gcc/graphite-dependences.c
+++ b/gcc/graphite-dependences.c
@@ -19,7 +19,7 @@ You should have received a copy of the GNU General Public 
License
 along with GCC; see the file COPYING3.  If not see
 .  */
 
-#define USES_ISL
+#define INCLUDE_ISL
 
 #include "config.h"
 
diff --git a/gcc/graphite-isl-ast-to-gimple.c b/gcc/graphite-isl-ast-to-gimple.c
index 562cee0..8108227 100644
--- a/gcc/graphite-isl-ast-to-gimple.c
+++ b/gcc/graphite-isl-ast-to-gimple.c
@@ -18,7 +18,7 @@ You should have received a copy of the GNU General Public 
License
 along with GCC; see the file COPYING3.  If not see
 .  */
 
-#define USES_ISL
+#define INCLUDE_ISL
 
 #include "config.h"
 
diff --git a/gcc/graphite-optimize-isl.c b/gcc/graphite-optimize-isl.c
index fe8a71a..170e535 100644
--- a/gcc/graphite-optimize-isl.c
+++ b/gcc/graphite-optimize-isl.c
@@ -18,7 +18,7 @@ You should have received a copy of the GNU General Public 
License
 along with GCC; see the file COPYING3.  If not see
 .  */
 
-#define USES_ISL
+#define INCLUDE_ISL
 
 #include "config.h"
 
diff --git a/gcc/graphite-poly.c b/gcc/graphite-poly.c
index efa39bf..a3f8ada 100644
--- a/gcc/graphite-poly.c
+++ b/gcc/graphite-poly.c
@@ -19,7 +19,7 @@ You should have received a copy of the GNU General Public 
License
 along with GCC; see the file COPYING3.  If not see
 .  */
 
-#define USES_ISL
+#define INCLUDE_ISL
 
 #include "config.h"
 
diff --git a/gcc/graphite-scop-detection.c b/gcc/graphite-scop-detection.c
index d026d4f..cea629b 100644
--- a/gcc/graphite-scop-detection.c
+++ b/gcc/graphite-scop-detection.c
@@ -19,7 +19,7 @@ You should have received a copy of the GNU General Public 
License
 along with GCC; see the file COPYING3.  If not see
 .  */
 
-#define USES_ISL
+#define INCLUDE_ISL
 
 #include "config.h"
 
diff --git a/gcc/graphite-sese-to-poly.c b/gcc/graphite-sese-to-poly.c
index 92ab2f9..a46b63c 100644
--- a/gcc/graphite-sese-to-poly.c
+++ b/gcc/graphite-sese-to-poly.c
@@ -18,7 +18,7 @@ You should have received a copy of the GNU General Public 
License
 along with GCC; see the file COPYING3.  If not see
 .  */
 
-#define USES_ISL
+#define INCLUDE_ISL
 
 #include "config.h"
 
@@ -47,16 +47,6 @@ along with GCC; see the file COPYING3.  If not see
 #include "tree-scalar-evolution.h"
 #include "domwalk.h"
 #include "tree-ssa-propagate.h"
-
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-
 #include "graphite.h"
 
 /* Assigns to RES the value of the INTEGER_CST T.  */
diff --git a/gcc/graphite.c b/gcc/graphite.c
index 3236006..c85823d 100644
--- a/gcc/graphite.c
+++ b/gcc/graphite.c
@@ -27,7 +27,7 @@ along with GCC; see the file COPYING3.  If not see
The wiki page http://gcc.gnu.org/wiki/Graphite contains pointers to
the related work.  */
 
-#define USES_ISL
+#define INCLUDE_ISL
 
 #include "config.h"
 #include "system.h"
diff --git a/gcc/graphite.h b/gcc/graphite.h
index 2f36ded..30c4d2c 100644
--- a/gcc/graphite.h
+++ b/gcc/graphite.h
@@ -23,29 +23,6 @@ along with GCC; see the file COPYING3.  If not see
 #define GCC_GRAPHITE_POLY_H
 
 #include "sese.h"
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-
-#ifdef HAVE_ISL_OPTIONS_SET_SCHEDULE_SERIALIZE_SCCS
-/* isl 0.15 or later.  */
-#include 
-
-#else
-/* isl 0.14 or 0.13.  */
-# define isl_stat int
-# define isl_stat_ok 0
-#endif
 
 typedef struct poly_dr *poly_dr_p;
 
diff --git a/gcc/system.h b/gcc/system.h
index 8151e0a..d5b2f85 100644
--- a/gcc/system.h
+++ b/gcc/system.h
@@ -669,6 +669,31 @@ extern int vsnprintf (char *, size_t, const char *, 
va_list);
 #include 
 #endif
 

Re: Speedup configure and build with system.h

[Richard Biener]

On Thu, Jan 21, 2016 at 5:57 PM, Michael Matz  wrote:
> Hi,
>
> this has bothered me for some time.  The gcc configure with stage1 feels
> like taking forever because some of the decl availability tests (checking
> for C function) include system.h, and that, since a while, unconditionally
> includes  and  under C++, and we meanwhile use the C++
> compiler for configure tests (which makes sense).  Now, the difference for
> a debuggable (but not even checking-enabled) cc1plus for a file containing
> just main():
>
> % cat blaeh.cc
> #include 
> #include 
> #include 
> #include 
> int main() {}
> % cc1plus -quiet -ftime-report blaeh.cc
>  TOTAL :   0.12 0.01 0.14
>
> (This is btw. three times as expensive as with 4.8 headers (i.e.
> precompile with g++-4.8 then compile with the same cc1plus as above,
> taking 0.04 seconds; the STL headers bloat quite much over time)
>
> Well, not quite blazing fast but then adding :
>
> % cc1plus -quiet -ftime-report blaeh-string.cc
>  TOTAL :   0.60 0.05 0.66
>
> Meeh.  And adding  on top:
>
> % cc1plus -quiet -ftime-report blaeh-string-alg.cc
>  TOTAL :   1.13 0.09 1.23
>
> So, more than a second for checking if some C-only decl is available, just
> because system.h unconditionally includes mostly useless STL headers.
>
> So, how useless exactly?  A whopping single file of cc1 proper needs
> , _two_ files need , and a single target has an unlucky
> interface in its prototypes and also needs .  (One additional
> header lazily uses std::string for no particular reason).  So we pay about
> 5 minutes build time per stage (there are ~400 libbackend.a files) for
> more or less nothing.
>
> So, let's include those headers only conditionally; I'm pretty sure it's
> not unreasonable for a source file, if it needs a particular STL facility
> to #define USES_abcheader (like one normally would have to #include
> ) before the "system.h" include.
>
> See the patch.  I've grepped for target or language dependencies on other
> STL types, and either they were already including the right header, or
> were covered with the new system.h (i.e. I've built all targets quickly
> for which grepping for 'std::' returned anything).  The genconditions.c
> change is for the benefit of aarch64 as well, and it single function
> aarch64_get_extension_string_for_isa_flags returning a std::string.
>
> What do people think?  Should I pass it through a proper bootstrap and put
> it to trunk?  It's a (developer time) regression, right? ;-)

Ok.

Thanks,
Richard.

I'm inclined to say #define INCLUDE_ALGORITHM is a better name,
but just bike-shedding...  and please convert the (bogus) ISL way of
achieving a similar thing.

I'm also inclined to say that we should remove  usage.  Not
sure about algorithm, but I'd say it's the same.

Richard.

>
> Ciao,
> Michael.
> * system.h (string, algorithm): Include only conditionally.
> (new): Include always under C++.
> * bb-reorder.c (toplevel): Define USES_ALGORITHM.
> * final.c (toplevel): Ditto.
> * ipa-chkp.c (toplevel): Define USES_STRING.
> * genconditions.c (write_header): Make gencondmd.c define
> USES_STRING.
> * mem-stats.h (mem_usage::print_dash_line): Don't use std::string.
>
> * config/aarch64/aarch64.c (toplevel): Define USES_STRING.
> * common/config/aarch64/aarch64-common.c (toplevel): Ditto.
>
> Index: bb-reorder.c
> ===
> --- bb-reorder.c(revision 232675)
> +++ bb-reorder.c(working copy)
> @@ -91,6 +91,7 @@
>  */
>
>  #include "config.h"
> +#define USES_ALGORITHM /* stable_sort */
>  #include "system.h"
>  #include "coretypes.h"
>  #include "backend.h"
> Index: final.c
> ===
> --- final.c (revision 232675)
> +++ final.c (working copy)
> @@ -43,6 +43,7 @@ along with GCC; see the file COPYING3.
> function_epilogue.  Those instructions never exist as rtl.  */
>
>  #include "config.h"
> +#define USES_ALGORITHM /* reverse */
>  #include "system.h"
>  #include "coretypes.h"
>  #include "backend.h"
> Index: genconditions.c
> ===
> --- genconditions.c (revision 232675)
> +++ genconditions.c (working copy)
> @@ -51,6 +51,7 @@ write_header (void)
> machine description file.  */\n\
>  \n\
>  #include \"bconfig.h\"\n\
> +#define USES_STRING\n\
>  #include \"system.h\"\n\
>  \n\
>  /* It is necessary, but not entirely safe, to include the headers below\n\
> Index: ipa-chkp.c
> ===
> --- ipa-chkp.c  (revision 232675)
> +++ ipa-chkp.c  (working copy)
> @@ -19,6 +19,7 @@ along with GCC; see the file COPYING3.
>  .  */
>
>  #include 

Speedup configure and build with system.h

[Michael Matz]

Hi,

this has bothered me for some time.  The gcc configure with stage1 feels 
like taking forever because some of the decl availability tests (checking 
for C function) include system.h, and that, since a while, unconditionally 
includes  and  under C++, and we meanwhile use the C++ 
compiler for configure tests (which makes sense).  Now, the difference for 
a debuggable (but not even checking-enabled) cc1plus for a file containing 
just main():

% cat blaeh.cc
#include 
#include 
#include 
#include 
int main() {}
% cc1plus -quiet -ftime-report blaeh.cc
 TOTAL :   0.12 0.01 0.14

(This is btw. three times as expensive as with 4.8 headers (i.e. 
precompile with g++-4.8 then compile with the same cc1plus as above, 
taking 0.04 seconds; the STL headers bloat quite much over time)

Well, not quite blazing fast but then adding :

% cc1plus -quiet -ftime-report blaeh-string.cc
 TOTAL :   0.60 0.05 0.66

Meeh.  And adding  on top:

% cc1plus -quiet -ftime-report blaeh-string-alg.cc
 TOTAL :   1.13 0.09 1.23

So, more than a second for checking if some C-only decl is available, just 
because system.h unconditionally includes mostly useless STL headers.

So, how useless exactly?  A whopping single file of cc1 proper needs 
, _two_ files need , and a single target has an unlucky 
interface in its prototypes and also needs .  (One additional 
header lazily uses std::string for no particular reason).  So we pay about 
5 minutes build time per stage (there are ~400 libbackend.a files) for 
more or less nothing.

So, let's include those headers only conditionally; I'm pretty sure it's 
not unreasonable for a source file, if it needs a particular STL facility 
to #define USES_abcheader (like one normally would have to #include 
) before the "system.h" include.

See the patch.  I've grepped for target or language dependencies on other 
STL types, and either they were already including the right header, or 
were covered with the new system.h (i.e. I've built all targets quickly 
for which grepping for 'std::' returned anything).  The genconditions.c 
change is for the benefit of aarch64 as well, and it single function 
aarch64_get_extension_string_for_isa_flags returning a std::string.

What do people think?  Should I pass it through a proper bootstrap and put 
it to trunk?  It's a (developer time) regression, right? ;-)


Ciao,
Michael.
* system.h (string, algorithm): Include only conditionally.
(new): Include always under C++.
* bb-reorder.c (toplevel): Define USES_ALGORITHM.
* final.c (toplevel): Ditto.
* ipa-chkp.c (toplevel): Define USES_STRING.
* genconditions.c (write_header): Make gencondmd.c define
USES_STRING.
* mem-stats.h (mem_usage::print_dash_line): Don't use std::string.

* config/aarch64/aarch64.c (toplevel): Define USES_STRING.
* common/config/aarch64/aarch64-common.c (toplevel): Ditto.

Index: bb-reorder.c
===
--- bb-reorder.c(revision 232675)
+++ bb-reorder.c(working copy)
@@ -91,6 +91,7 @@
 */
 
 #include "config.h"
+#define USES_ALGORITHM /* stable_sort */
 #include "system.h"
 #include "coretypes.h"
 #include "backend.h"
Index: final.c
===
--- final.c (revision 232675)
+++ final.c (working copy)
@@ -43,6 +43,7 @@ along with GCC; see the file COPYING3.
function_epilogue.  Those instructions never exist as rtl.  */
 
 #include "config.h"
+#define USES_ALGORITHM /* reverse */
 #include "system.h"
 #include "coretypes.h"
 #include "backend.h"
Index: genconditions.c
===
--- genconditions.c (revision 232675)
+++ genconditions.c (working copy)
@@ -51,6 +51,7 @@ write_header (void)
machine description file.  */\n\
 \n\
 #include \"bconfig.h\"\n\
+#define USES_STRING\n\
 #include \"system.h\"\n\
 \n\
 /* It is necessary, but not entirely safe, to include the headers below\n\
Index: ipa-chkp.c
===
--- ipa-chkp.c  (revision 232675)
+++ ipa-chkp.c  (working copy)
@@ -19,6 +19,7 @@ along with GCC; see the file COPYING3.
 .  */
 
 #include "config.h"
+#define USES_STRING
 #include "system.h"
 #include "coretypes.h"
 #include "backend.h"
Index: mem-stats.h
===
--- mem-stats.h (revision 232675)
+++ mem-stats.h (working copy)
@@ -200,7 +200,9 @@ struct mem_usage
   static inline void
   print_dash_line (size_t count = 140)
   {
-fprintf (stderr, "%s\n", std::string (count, '-').c_str ());
+while (count--)
+  fputc ('-', stderr);
+fputc ('\n', stderr);
   }
 
   /* Dump header with NAME.  */
Index: system.h