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.
We could reserve a fixed range for plugin builtins if you think that is
desirable.
> 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.
> 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;
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;
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.
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.
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.
--
Michael Meissner, IBM
5 Technology Place Drive, M/S 2757, Westford, MA 01886-3141, USA
meiss...@linux.vnet.ibm.com fax +1 (978) 399-6899
