This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Patch to categorize builtins.def


> In my defense, "ffs" is in the string section not math.  The guideline
> I tried to follow is which header a function appears in.  "ffs"
> appears in "strings.h".  Similarly, sprintf appears in "stdio.h" so
> it's in the stdio section.  It's possible I may have made a mistake in
> following this pattern, but I don't want to leave the impression that
> I did it at random.

Ok, the pattern is clearer once explained.  It wasn't that I was
unhappy with the categories themselves, just that there are often
borderline cases.  For example, "abs" and "labs" are defined in
<stdlib.h> not <math.h>...


> I'd like to work out something mutually acceptable.  My concern
> relates to how we work on groups of stuff.  Yours seems to be
> synchronization.  Can you suggest a way to solve both problems
> cleanly?  I'm also willing to let the patch be reverted if you feel
> strongly about it and we cannot solve both.

My concern is also with groups of stuff.  Many of the examples I
gave, only deal with subsets (often just the mathematical builtins
which fits your scheme perfectly), but almost universally its
advantagous to then treat each group/subset alphabetically.

So although there are numerous ways to susbet things, i.e. all the
builtins that can't return a negative value (which has overlaps with
string, math and misc) its easier to check concordance if that subset
is sorted.  So whilst categories helps one part of the code or another,
alphabetization helps them all.


For example, when we compare our lists of mathematical builtins, its
more important that "cos" comes before "sin", than it is that we have
to ignore "strcmp".

I'll volunteer to do both the following myself, but I offer them as
difficult clean-ups without atleast partial alphabetization.  The first
is making sure that all of GCC builtins are documented, and that they
are documented in the correct section of extend.texi.  I/we have already
done much of the work to keep the documentation sorted, so the task
is half-way done.

The second problem is the clean-up of the "call when not optimizing
list", between lines 4893-4974 of builtins.c.  This list must contain
all the builtins in the switch statement between lines 5013-5485 that
exist in function call form.  Often builtins are added but forgetting
to add them to the "don't inline at -O0" clause.  For example, CABS!
Maintenance of this list is obviously easier if the sense is reversed,
which would also significantly shorten it.  i.e. we list the GCC_BUILTINs
that don't have fallbacks.  Forgetting to update the list in future
would then should up during testing as a failure, rather than a slower
compiler!

If you'd like to tackle either the above two problems, I think it would
foster an new found appreciation for what I was trying to achieve by
my original alphabetization patch.  :>  As I said above I'm more than
happy to do these myself, but thinking about the "machanics" of these
changes should explain why categorization has just made these problem
and their review much harder.


I feel I haven't offered a compromise, which isn't constructive.  What
if we just hold off of the categorization of builtins.def until after
the major code clean-ups and reorganizations are done?  Ordering of the
builtins is to aid synchronization is most beneficial when things are
changing rapidly.  I suspect the number of GCC builtins will double or
triple over the next month or two, but will then slow significantly
after that.


Finally, I'm more than happy to concede if you feel strongly.  Its only
an inconvenience, and is trivially worked around [I can always run sort
on builtins.def myself now that you've made that possible, thanks!].

Infact, I'm not even sure why I'm arguing, other than reintroducing
categories seems a bit retrograde.  builtins.def has always had some
form of categorization, double math functions were kept together,
as were float math functions, as were long double math functions,
the string functions were mostly in the same place, the va_args stuff,
and the stdio functions that referenced FILE* were kept separate from
those that didn't, and the _unlocked versions were separate still in
these two categories.  There comes a point when organization/structure
isn't helpful!

Roger
--


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]