This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [RFC] Builtin infrastructure change
On Tue, Oct 04, 2011 at 02:44:00PM +0200, Richard Guenther wrote:
> On Tue, Oct 4, 2011 at 2:07 AM, Michael Meissner
> <meissner@linux.vnet.ibm.com> wrote:
> > On Sat, Oct 01, 2011 at 02:11:27PM +0000, Joseph S. Myers wrote:
> >> On Fri, 30 Sep 2011, Michael Meissner wrote:
> >>
> >> > Is this enough of a savings to continue on? ?I'm of two minds about it, one is
> >>
> >> The thing to measure is not so much memory as startup time (how long it
> >> takes to compile an empty source file), which is important for libraries
> >> and programs using a coding style with lots of small source files.
> >
> > With my current changes which has modified the standard builtins to be lazy,
> > but I haven't yet done the machine dependent builtins, I saw a difference of
> > 0.0022 seconds (0.0170 vs. 0.0148) on my 3 year old Intel core 2 laptop. ?I did
> > 14 runs in total, and skipped the fastest 2 runs and slowest 2 runs, and then
> > averaged the 10 runs in the middle. ?I built boostrap builds with release
> > checking with the top of subversion head without changes and with my changes.
> >
> > So at this point, I'm wondering whether it is worth it to finish the
> > optimization for lazy builtins.
>
> I think it is.
>
> +/* Return the tree node for a builtin function or NULL, indexing into the
> + array. */
> +static inline tree
> +built_in_set_decl_add (enum built_in_function fncode, int addend)
> +{
> + return built_in_decls ((enum built_in_function)(((int)fncode) + addend));
> +}
>
> this doesn't seem to "set" anything. Mistake?
Yes, it was a mistake (though once the lazy builtins are done, it may do a set
to create the function decl the first time the builtin is touched).
> +static inline tree
> +built_in_decls (enum built_in_function fncode)
>
> I'd prefer singular, built_in_decl () instead of plural.
Ok. I was just using the array name, but singular is better.
> +static inline tree
> +implicit_built_in_decls (enum built_in_function fncode)
>
> Likewise.
Ok, if I'm going to change the name anyway, I think I will make it
built_in_decl_implicit instead.
> +/* Initialize an implicit builtin function. */
> +static inline void
> +built_in_set_implicit (enum built_in_function fncode, tree implicit)
>
> and built_in_set_implicit_decl (or rather set_implicit_built_in_decl - hm,
> I guess I'm now bikeshedding ;)).
> The patch is ok with the built_in_set_decl_add mystery resolved
> (I'd best not have the function at all but perform the ugly add and casting
> in the few callers -- it _is_ ugly to do that after all, so it might as well
> look so ;)).
Originally I had kept the math inline, but some of the OMP functions were
running into the 80 character line limit, particularly with the need to make
sure everything correctly cast to int or enum for C++.
> It would be nice to use singular/plural consistently (different currently
> for set and get, I prefer singular). The rest of the bikeshedding - oh well ;)
And whether it is builtin or built_in, since the compiler is inconsistant.
--
Michael Meissner, IBM
5 Technology Place Drive, M/S 2757, Westford, MA 01886-3141, USA
meissner@linux.vnet.ibm.com fax +1 (978) 399-6899