Re: Speedup configure and build with system.h

[Oleg Endo <oleg.endo@t-online.de>]

On Thu, 2016-01-21 at 18:10 +0100, Richard Biener wrote:
> On Thu, Jan 21, 2016 at 5:57 PM, Michael Matz <matz@suse.de> 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 <string> and <algorithm> 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 <stdio.h>
> > #include <cstring>
> > #include <utility>
> > #include <new>
> > 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 <string>:
> > 
> > % cc1plus -quiet -ftime-report blaeh-string.cc
> >  TOTAL                 :   0.60             0.05             0.66
> > 
> > Meeh.  And adding <algorithm> 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
> > <string>, _two_ files need <algorithm>, and a single target has an
> > unlucky
> > interface in its prototypes and also needs <string>.  (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
> > <abcheader>) 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 <string> usage.  Not
> sure about algorithm, but I'd say it's the same.
> 

<string> and <algorithm> 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