[PATCH] Remove insert_default_attributes langhook.

[Zack Weinberg]

Roger Sayle <roger@eyesopen.com> writes:

> This patch is the second part of my patch to remove the last few
> functions from builtin-attrs.def.  The first installment moved the
> functionality to GCC builtins, this final installment cleans-up
> all of the dead-code now that that insert_default_attributes is
> no longer required.
>
> This contains both of the clean-ups requested by Zack (the comment
> describing DEF_FN_ATTR was actually already removed from the top of
> builtin-attrs.def by the first patch) and Joseph Myers' suggested
> removal of flag_noniso_default_format_attributes which is also
> unused.  But as you can see from the ChangeLog these were just the
> tip of the iceberg of the fallout.
>
> Whilst I appreciate Zack's concerns that there may be a nontrivial
> start-up cost associated with GCC's builtins, predeclaring under
> 200 builtins is significantly more efficient than the code we've
> just removed, which would do a sequential comparison against each
> builtin in insert_default_attributes, which was called once for
> every identifier declaration in a source file, which averages at
> over 2000 declarations per compilation unit in a GCC bootstrap.
>
> However, I do have plans to attempt to reduce the cost of building
> predeclared builtins at start-up.  The first and obvious step is to
> time a "-fno-builtin" bootstrap of mainline to determine the
> cost/benefit ratio of GCC's builtins.  This can then form a baseline
> by which to assess future builtins changes.

Thanks for considering the problem.  I did not mean to give the
impression that I didn't like the change itself; I'm just concerned
about front-loading more and more cost and therefore slowing down
compilation of simple programs.  Tight loops invoking the compiler on
lots of small source files are a relatively common case - glibc build,
gcc testsuite, etc.

> I'm pretty sure insert_default_attributes has no part in GCC's
> future.  Unless we have huge numbers of builtins to create at
> start-up, the overhead of per-declaration processing (such as a
> second hash-table lookup or even perfect hashing) on one of GCC's
> critical paths is just too expensive.  A better solution is to
> reduce the constant start-up overhead, by using static trees or a
> scheme like PCH.  This not only helps "builtin functions", but also
> predeclared types, floating point constants and all the other tree
> nodes that we create every cc1 invocation.

This sounds like a promising approach.  We'll need generational GC to
make it work properly, but we need that anyway.

> The following patch has been tested on i686-pc-linux-gnu with a complete
> "make bootstrap", all languages except treelang, and regression tested
> with a top-level "make -k check" with no new failures.
>
> Ok for mainline?

Yes.