On Mon, Apr 4, 2011 at 9:31 PM, Michael Meissner <meiss...@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 > meiss...@linux.vnet.ibm.com fax +1 (978) 399-6899 >
