Re: Patch to categorize builtins.def

[Roger Sayle <roger at eyesopen dot com>]

On Sat, 2 Aug 2003, Kaveh R. Ghazi wrote:
> Why isn't this list exactly those builtins for which FALLBACK_P is
> true vs false?

It would be very nice/simple to assert those semantics.  We'd replace a
100+ case switch statement with "DECL_ASSEMBLER_NAME_SET_P (fndecl))".


> What exceptions to this exist?

One motivation for alphabetization was to determine exactly this.

Clearly, there are currently some library builtins that get expanded
even at -O0.  i.e. the list currently doesn't follow FALLBACK_P.
"Why" is the difficult question.  Hopefully, these are just oversights
or can be changed.  The testsuite would also need to be checked to see
if there are any tests that rely on builtin expansion at -O0 (and
corrected appropriately).

Playing devil's advocate, there may be borderline cases such as fabs or
sqrt where expanding a single RTL insn inline may produce a faster
compiler than expanding a libcall sequence.  This assumes that -O0 means
optimize for compile-time.  Then there's also the point of view that if
expanding builtins has negligible effect on compile-time, why not always
expand them to minimize the differences between optimization levels.
This last position would need to be refuted/supported by experiment.
These views aren't my own, but should be taken under consideration when
cleaning up this code.

Does anyone have any objections, if Kaveh and I agree upon the semantics
of *always* disabling library builtin expansion at -O0, which would
dramatically clean-up this piece of code?  Its also one less thing to
worry about when adding a new builtin to GCC.  Constant folding at the
tree-level wouldn't be affected.

Roger
--