This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: Patch to categorize builtins.def
- From: Roger Sayle <roger at eyesopen dot com>
- To: "Kaveh R. Ghazi" <ghazi at caip dot rutgers dot edu>
- Cc: Zack Weinberg <zack at codesourcery dot com>, <gcc-patches at gcc dot gnu dot org>
- Date: Sat, 2 Aug 2003 07:17:21 -0600 (MDT)
- Subject: Re: Patch to categorize builtins.def
Hi Kaveh and Zack,
Oh no! I guess its too late for me to protest against the categorization
of builtins.def. The patch has been approved and committed and is pretty
much a "fait acompli".
However, I'd like to point that are numerous other places in GCC where
lists of builtins need to be maintained that would have been much
easier to modified/checked if the builtins.def list was kept alphabetical.
The first is the documentation. All of GCC's builtins are listed twice
in extend.texi, once as a global list in alphabetical order, then most
of them are repeated again in categories for LIB_BUILTIN, C99_BUILTIN,
EXT_BUILTIN etc.. Checking that all of GCC's builtins are documented
(I believe Joseph has already caught Kaveh out recently :) is made much
easier for both sets with a single sorted list.
One could argue categorizing builtins.def based upon LIB_BUILTIN,
C99_BUILTIN, EXT_BUILTIN is just a reasonable division as by math,
string, stdio and misc. Where did we put sprintf by the way, string
or stdio? I also notice "ffs" is math, but "popcount" is misc?
Next there's the "Call when not optimizing" at the top of expand_builtin.
Once again sorted lists show what's there. More importantly one of the
changes that I was hoping could be tackled once we had a sorted reference
list is to change the sense of this list to "Always expand" which I fairly
sure is a much shorter list.
Similarly, keeping the main switch in expand_builtin sorted would make
it easier to track which builtins have special expansions.
Finally there are the lists in mathfn_built_in, expand_builtin_mathfn,
expand_builtin_mathfn2, integer_valued_real_p, expand_tree_builtin,
convert_to_real, fold, tree_expr_nonneagtive_p... I'm sure I don't
have to go on.
Many of the builtins lists in the above functions are already sorted
alphabetically. One possibility might be to reorder the source code
to match the new categories?
No hardship. We've lived with a random builtins.def in the past.
I'm guessing four or five categories can't be any worse. My apologies,
I was fast asleep when the issues were discussed.
Roger
--