[PATCH] Add infrastructure to merge standard builtin enums with backend builtins

[Richard Guenther]

On Thu, Aug 25, 2011 at 10:35 PM, Michael Meissner
<meissner@linux.vnet.ibm.com> wrote:
> On Wed, Aug 24, 2011 at 11:06:55AM +0200, Richard Guenther wrote:
>> This basically would make DECL_BUILT_IN_CLASS no longer necessary
>> if all targets where converted, right?  (We don't currently have any
>> BUILT_IN_FRONTEND builtins).  That would sound appealing if this
>> patch weren't a partial transition ;)
>
> Or we could reduce it to 1 bit if we aren't going to change all of the
> backends.
>
>> Now for the possible downsides.  How can we reliably distinguish
>> middle-end from target builtins for purpose of lazy initialization?
>> Doesn't this complicate the idea of "pluggable" targets, thus
>> something like a hybrid ppc / spu compiler?  In this light merging
>> middle-end and target builtin enums and arrays sounds like a step
>> backward.
>
> If we are willing to pay the storage costs, we could have 1 or 2 bytes for
> builtin owner, and 2 bytes for builtin index, and then reserve 0 for standard
> builtins and 1 for machine dependent builtins.  However, then you still have
> the potential problem that sooner or later somebody else will omit the checks.

I don't think that the issue you only can index BUILT_IN_NORMAL builtins
in built_in_decls is an issue and worth thinking about at all.  It's simply
bugs.

> We could reserve a fixed range for plugin builtins if you think that is
> desirable.

Oh, plugin builtins - I didn't even think about the possibility of having
those ;)

In the end I think we should stick with BUILT_IN_CLASS and maybe
add BUILT_IN_PLUGIN then ;)

>> What I _do_ like is having common machinery for defining builtins.
>> Though instead of continuing the .def file way with all the current
>> warts of ways of adding attributes, etc. to builtins I would have
>> prefered a genbuiltins.c program that can parse standard C
>> declarations and generate whatever is necessary to setup the
>> builtin decls.  Thus, instead of
>>
>> DEF_GCC_BUILTIN        (BUILT_IN_CLZ, "clz", BT_FN_INT_UINT,
>> ATTR_CONST_NOTHROW_LEAF_LIST)
>>
>> have simply
>>
>> int __builtin_clz (unsigned int) __attribute__((const,nothrow,leaf));
>>
>> in a header file which genbuiltins.c would parse.  My first idea
>> when discussing this was a -fgenbuiltins flag to the C frontend
>> (because that already can do all the parsing ...), but Micha suggested
>> a parser that can deal with the above is easy enough to "re-implement".
>
> Yes, that is certainly do-able.  My main intention is to see what kind of
> infrastructure people wanted before changing all of the ppc builtins.

Sure.  I agree that all the duplicated code we have in backends for a
way to create target builtins, defining enums (or not) for them and
having a way to reference them for targetm.builtin_decl (or not) is bad.
But unifying those, or providing common infrastructure for them should
be orthogonal to the issue whether we want to "merge" the builtin
classes or their storage in some way (I think we don't).  It would of
course be nice if the infrastructure to create taget builtins were
generic enough to eventually handle builtin creation in the middle-end
(and the frontends) as well.

>> Hm, I guess this pushes back a bit on your patch.  Sorry for that.
>> If you're not excited to try the above idea, can you split out the
>> pieces that do the .def file thing for rs6000, keeping the separation
>> of md and middle-end builtin arrays and enums?
>
> I have several goals for the 4.7 time frame:
>
>  1) Make target attribute and pragma enable appropriate machine dependent
>     builtins;

That's now something completely new ;)  Why do we need builtins for this?

>  2) Make it less likely we will again be bitten by code that blindly
>     references built_in_decl without checking if it is MD or standard;

I don't think this is important at all.  Proposed solution: transition
builtin decl access to a functional interface:

tree built_in_decl (enum built_in_code)

which when building with C++ will get you warnings if indexed with
a bougs enum type or an integer type.

>  3) Make at least the MD builtins created on demand.  It would be nice to do
>     the standard builtins as well, but that may somewhat more problematical.
>     I do think all references to built_in_decl and implicit_built_in_decl
>     should be moved to a macro wrapper.

To a (inline) function wrapper with the same name, indeed.

> If we restrict the types and attributes for a C like header file, it shouldn't
> be that hard (famous last words).  I would think adding #ifdef also, so:
>
>        #ifdef __ALTIVEC__
>        extern vector float __builtin_altivec_vaddfp (vector float, vector
>                                float) __attribute__ ((...));
>        #endif
>
> The backend would need to specify a list of valid #ifdef's and the mapping to
> TARGET_<xxx>, and valid extra types with a mapping to the internal type node.

Yes.  For the middle-end/frontend stuff we also need a way to specify
the difference between C89 and C99 builtins and GCC internal builtins.

Not sure if I'd use #ifdef like above or simply stick to .def file like
attributions in comments like

/* TARGET(ALTIVEC) */
extern vector float __builtin_altivec_vaddfp (vector float, vector
float) __attribute__ ((...));

/* LANG(C99) */
double cbrt (double, double) __attribute__ ((...));

we also have fancy things like conditionally adding attributes, for example
the ATTR_MATHFN_FPROUNDING stuff.  Using #ifdefs for this would
work, I think there is a special macro defined for -frounding-math.

The idea certainly needs some thoughts, and the target builtins probably
have less feature requirements than the middle-end builtins.def stuff.

The .h file could also serve as a container for builtin documentation.

> The alternative is something like what Kenney and Mike are doing in their
> private port, where they have new syntax in the MD file for builtins.

But are those user-exposed builtins?  Certainly interesting to combine
builtin definition and the instruction it expands to.

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
>