Displaying 4 results from an estimated 4 matches for "unioncast".
Did you mean:
unicast
2010 Jan 15
2
[LLVMdev] [PATCH] - Union types, attempt 2
...tisfy
alignment constraints, but that would be architecture dependent and I
assume should therefore be invisible). Correct?
If that argument is persuasive, then the following seems a bit more
consistent with the existing syntax:
; Manipulation of a union register variable
%myUnion = unioncast i32, %myValue to union {i32, float}
%fieldValue = unioncast union {i32, float} %myUnion to i32
; %fieldValue == %myValue
This specialized union cast fits the pattern of having specialized cast
operations between value and pointer as opposed to two values or two
pointers.
That's en...
2010 Jan 16
0
[LLVMdev] [PATCH] - Union types, attempt 2
...that would be architecture dependent and I
> assume should therefore be invisible). Correct?
>
> If that argument is persuasive, then the following seems a bit more
> consistent with the existing syntax:
>
> ; Manipulation of a union register variable
> %myUnion = unioncast i32, %myValue to union {i32, float}
> %fieldValue = unioncast union {i32, float} %myUnion to i32
> ; %fieldValue == %myValue
>
> This specialized union cast fits the pattern of having specialized cast
> operations between value and pointer as opposed to two values or two...
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