Displaying 4 results from an estimated 4 matches for "newunionptr".
2010 Jan 15
2
[LLVMdev] [PATCH] - Union types, attempt 2
...want a pointer to one of the alternatives in the union
you'd just cast one pointer to another; to avoid alignment adjustments
on what is supposed to be a no-op that cast probably shouldn't be
bitcast. So what about
%intPtr = unioncast union {i32, float}* %myUnionPtr to i32*
%newUnionPtr = unioncast i32* %intPtr to union {i32, float}*
; %newUnionPtr == %myUnionPtr
I'm not necessarily advocating overloading one keyword ('unioncast')
that way, though I note that it should always be unambiguous based on
whether the operands are values or pointers (LLVM seems to hav...
2010 Jan 16
0
[LLVMdev] [PATCH] - Union types, attempt 2
...e alternatives in the union
> you'd just cast one pointer to another; to avoid alignment adjustments
> on what is supposed to be a no-op that cast probably shouldn't be
> bitcast. So what about
>
> %intPtr = unioncast union {i32, float}* %myUnionPtr to i32*
> %newUnionPtr = unioncast i32* %intPtr to union {i32, float}*
> ; %newUnionPtr == %myUnionPtr
>
> I'm not necessarily advocating overloading one keyword ('unioncast')
> that way, though I note that it should always be unambiguous based on
> whether the operands are values or poin...
2010 Jan 15
0
[LLVMdev] [PATCH] - Union types, attempt 2
On Fri, Jan 15, 2010 at 12:41 AM, Joachim Durchholz <jo at durchholz.org>wrote:
> Talin schrieb:
>
> Well, the fact that union members have to be indexed by number means that
>> the ordering has to be part of the type - so even though type-theoretically
>> union { i32, float } is the same as union { float, i32 }, in my
>> implementation they are distinct types.
2010 Jan 15
2
[LLVMdev] [PATCH] - Union types, attempt 2
Talin schrieb:
> Well, the fact that union members have to be indexed by number means
> that the ordering has to be part of the type - so even though
> type-theoretically union { i32, float } is the same as union { float,
> i32 }, in my implementation they are distinct types. However, from the
> standpoint of a frontend, this is not a great concern, because the
> frontend