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
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.
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.
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.
(May be this is over clarification)
So an intrinsic declared with 'ifavpAny' can take different overloaded form such as
From llvm.xyz(i32) to llvm.xyz(4xi32) ?
Regards,
Shahid
Shahid, Asghar-ahmad wrote:
So an intrinsic declared with 'ifavpAny' can take different overloaded form such as
From llvm.xyz(i32) to llvm.xyz(4xi32)
Yes, that's correct. Just to fix the notation, let's use real code
def llvm_any_ty : LLVMType<Any>;
def int_experimental_gc_result : Intrinsic<[llvm_any_ty], [llvm_i32_ty]>;
Then:
%call1 = call i32* @llvm.experimental.gc.result.p0i32(...)
%call1 = call float @llvm.experimental.gc.result.f32(...)
%call1 = call zeroext i32 @llvm.experimental.gc.result.i32(...)
%call1 = call zeroext <2 x i32> @llvm.experimental.gc.result.v2i32(...)
etc.
I hope to have it properly functioning soon.
This looks great. 
Thanks for pursuing this.
Philip
(The following is an utter tangent from the original question and is my personal opinion only.) First Class Aggregates (FCAs) - which include arrays and structs - are in a weird middle ground of being supported, but not really optimized. Part of the problem is that no one has expressed a clear use case for them. If we decided they were just a convenience for the frontend, we could lower them early. However, this would give up some potential optimization benefit, so there’s been a reluctance to do that. Instead, we’re left in this awkward position where they ‘work’ but aren’t really recommended for use. To fix this, we really need an active contributor who wants to use them and drive things forward. That hasn’t happen to date. Unfortunately, I think we’ve managed to drive away a couple of folks who might have become that person due to the slow and rambling debates that tend to arise on FCA review threads. This will eventually get resolved, but I don’t see that happening in the immediate future. Philip