Re: [RFC] Creating builtin functions on demand

[Richard Guenther <richard dot guenther at gmail dot com>]

On Mon, Apr 4, 2011 at 9:31 PM, Michael Meissner
<meissner@linux.vnet.ibm.com> wrote:
> I am looking at finishing up the PowerPC support for functions compiled with
> target specific options, and the PowerPC will have the same problem that the
> x86 has, namely in order to support target functions, you need to have all of
> the machine specific builtins created, even if the user did not say -m<foo>,
> because they might use the appropriate pragma or attribute to compile code for
> a different machine.
>
> As far as I could tell with a quick search:
> ? ?x86 has ?818 machine specific builtins
> ? ?ppc has ?958 machine specific builtins
> ? ?arm has ? 90 machine specific builtins
> ? ?mips has 262 machine specific builtins
>
> Ideally, these should all be created on the first usage. ?Not only is the space
> wasted for the tree decl itself, but there is the space for representing the
> argument list. ?We should put some infrastructure into GCC 4.7 that helps
> automate this process.
>
> I'm wondering what the various maintainers feel we need in terms of
> infrastructure for these create on demand functions? ?Should we put the
> majority of non-machine dependent builtins into create on demand as well?

Maybe, but it's not that important.

> Do we want to have the ability to make the enum's for MD builtin functions to
> be in the same space as the non-MD builtins. ?I have had to track down several
> bugs where code was not checking if the builtin class was BUILT_IN_NORMAL
> before indexing into the built_in_decl arrays.

Yes, we do.  Places not checking the builtin class are simply bogus.

> Obviously, we need to look at built_in_decl and implicit_built_in_decl uses. ?I
> would probably make new macros to replace those two arrays (with GET and SET
> versions), and poison the old usage.

I'd separate the target/non-target builtin issue for now (we have some
general issues with non-target builtins and checks for their
"availability").  As for target builtins we do already have a target hook
that gets you a builtin decl for a function-code, what we lack is
a proper way to integrate with frontend name-lookup that doesn't
rely on the current way of simply injecting all names into it.
That's also where the current scheme is lacking - even for non-target
builtins we want to know in the middle-end if the user provided
a (compatible) declaration of the builtin, but currently we only have
partitioned the set of builtins into C standard groups.

Richard.

>
> --
> 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
>