llvm dev - Jan 2015 - [LLVMdev] Overloaded intrinsics: name explosion

Hi,

So, we currently have gc.result.int, gc.result.float. gc.result.ptr,
gc.relocate, and gc.statepoint. gc.statepoint's signature is fine with
a iPTRAny as the first argument. gc.result is in trouble, because none
of the signatures admit even a simple array of integers, and there's
no aAny. And certainly no vectors. So we can get a gc.result.vector to
add to this mess, and admit [1] to make iAny work with integer arrays
(and fAny work with float arrays). Then we can't have an array of
pointers.

gc.relocate suffers from the same problem: we want to be able to
relocate a vector of pointers, but it's simply not possible with its
signature.

My proposal is to:
1. Introduce aAny.
2. Make iAny work with integer arrays (they already work with integer
vectors), fAny work with float arrays.
3. Introduce ifavpAny to admit basically anything, and clean up the
user-facing interface.

What do people think?

Ram

[1]: http://reviews.llvm.org/D6988

On 01/15/2015 03:33 PM, Ramkumar Ramachandra wrote:
> Hi,
>
> So, we currently have gc.result.int, gc.result.float. gc.result.ptr,
> gc.relocate, and gc.statepoint. gc.statepoint's signature is fine with
> a iPTRAny as the first argument. gc.result is in trouble, because none
> of the signatures admit even a simple array of integers, and there's
> no aAny. And certainly no vectors. So we can get a gc.result.vector to
> add to this mess, and admit [1] to make iAny work with integer arrays
> (and fAny work with float arrays). Then we can't have an array of
> pointers.
>
> gc.relocate suffers from the same problem: we want to be able to
> relocate a vector of pointers, but it's simply not possible with its
> signature.
>
> My proposal is to:
> 1. Introduce aAny.
Having a generic any type seems fine.  I assume you'd create something 
like an llvm_any_type in Intrinsics.td?
> 2. Make iAny work with integer arrays (they already work with integer
> vectors), fAny work with float arrays.
This, I'm not sure about.  Not opposed or anything, just unsure. 
Thoughts by anyone else?

(I'm assuming you're referring to llvm_anyint_ty and llvm_anyfloat_ty.  
If not, please clarify.)
> 3. Introduce ifavpAny to admit basically anything, and
Er, what?  I have no idea what ifavpAny stands for.
> clean up the
> user-facing interface.
Only after the rest has landed and is stable.  For the experimental 
intrinsics (gc.relocates, gc.result) this is fine.  We'd have to talk 
about versioning if these are used anywhere else.
>
> What do people think?
>
> Ram
>
> [1]: http://reviews.llvm.org/D6988

Philip Reames wrote:
>> 1. Introduce aAny.
>
> Having a generic any type seems fine.  I assume you'd create something
like
> an llvm_any_type in Intrinsics.td?
That's precisely what ifavpAny is about: integer, float, array,
vector, pointer Any. aAny is meant for array-Any, and I wonder why so
few people care about arrays. I'll go ahead with Any and
llvm_any_type.