RFR: 8330851: C2: More efficient TypeFunc creation

[Dean Long]

On Mon, 18 Nov 2024 19:15:39 GMT, Dean Long <dlong at openjdk.org> wrote:

>>> For example, new_array_Type() when passes NOTNULL and INT and returns NOTNULL could be represented by something like "NIN".
>> 
>> There's definitely some room for improvement here, but, frankly speaking, stringy descriptors don't look appealing to me. Why not simply introduce `TypeFunc` factory methods which explicitly accept argument/return `Type`s instead? Probably, variadic functions are a good fit here, but even if it's not the case, there are rather few arities used (single return value - void, 1 slot, or 2 slots, plus up to 8 arguments). And that would eliminate lots of boilerplate code as well.
>
>> > For example, new_array_Type() when passes NOTNULL and INT and returns NOTNULL could be represented by something like "NIN".
>> 
>> There's definitely some room for improvement here, but, frankly speaking, stringy descriptors don't look appealing to me. Why not simply introduce `TypeFunc` factory methods which explicitly accept argument/return `Type`s instead? Probably, variadic functions are a good fit here, but even if it's not the case, there are rather few arities used (single return value - void, 1 slot, or 2 slots, plus up to 8 arguments). And that would eliminate lots of boilerplate code as well.
> 
> Good idea.

> @dean-long @iwanowww any suggestion for this one ?

You have several choices for creating factories for TypeTuple::make_domain() and TypeFunc::make() that take a variable number of arguments:
1) varargs
TypeFunc* TypeFunc::make(int nargs, Type* return_type, ...) { ... }
2) overloading
TypeFunc* TypeFunc::make(Type* return_type, Type* arg1) { /* 1 arg */ }
TypeFunc* TypeFunc::make(Type* return_type, Type* arg1, Type* arg2) { /* 2 args */ }
3) default value
TypeFunc* TypeFunc::make(Type* return_type, Type* arg1, Type* arg2 = nullptr, Type* arg3 = nullptr) { ... }
4) arrays
TypeFunc* TypeFunc::make(int nargs, Type* types[]) { ... }

Varargs is probably easiest, but I would be tempted to choose arrays if I thought it could get us all the way to read-only static constexpr data.  Unfortunately, there are some details that get in the way, such as adding Type::HALF for LP64 and adding boiler-plate fields before the TypeFunc::Parms slot.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21782#issuecomment-2504966794