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

[Mike Stump <mikestump at comcast dot net>]

On Aug 26, 2011, at 7:19 AM, Michael Meissner wrote:
>>> 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.
> 
> Yes, these are user exposed builtins.  Massive amounts of user exposed builtins
> (Mike said he needs 13 bits for the builtin index).  I think it would be better
> if Mike comments on this.

I gave the quick intro yesterday.  You wind up specifying the built-ins that you have, and the generator does things like assign enum values, create a file that appears the builtins into the user name space from the __builtin_ namespace, generate compilation test cases for all the built-ins with all different types they support.  Generate executable testcases to ensure everything works flawlessly.  We have mods to the overload builtin mechanism so that one can do things like:

template <class T>
T foo(T x, T y) {
  x = add(x, y);
  return x;
}

Or, if you perfer the C version:

int fooi(int x, int y) {
  return add(x, y);
}

short foos(short x, short y) {
  return add(x, y);
}

and have it work out just fine when T is instantiated with all the various types that are supported by the hardware, and it works in C.  This permits a nice api for the machine builtins, as you don't have to mangle in types into the builtin-name.  The system is complete enough to handle the needs of anything coming down the pike in the next decade.  It can handle input/output parameters that have register assignments.  It can handle reference parameters (like the input/output parameters, but these are done as values in memory.  The generator builds up _all_ the types one needs, handles all the registration and all the wiring up for codegen.  There is a mechanism to remap arguments going to the rtl generators, so the operand ordering of the builtin doesn't have to match the operand ordering of the md pattern for the semantics that back the builtin.  There is a beefy macro system built into the generator so that you can have nice simple patterns and it is beefier than the iterators one can use today.  So, for example, we have:

(define_special_iterator imath3 [add sub mul])

to define some built-ins that are regular with respect to the operation, but, this isn't a code nor mode iterator, it just iterators the pattern with the string substituted.  For machines with any regularity, the patterns wind up being smaller and easier to maintain.  I'd be happy to answer questions about it.