RFR: 8330851: C2: More efficient TypeFunc creation

[Amit Kumar]

On Wed, 27 Nov 2024 23:18:22 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.
>> 
>> 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.

Thanks for the reviews @dean-long @iwanowww . Are you running test on this one or should I move ahead with integration then ?

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

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