[LLVMdev] Overloaded intrinsics: name explosion

[Philip Reames]

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