[LLVMdev] [PATCH] - Union types, attempt 2

Talin viridia at gmail.com
Thu Jan 14 20:27:09 PST 2010


I'm still working on the next patch, it's going somewhat slowly. I wanted to
create a unit test that actually created a union, and in order to do that I
had to implement constant unions. And rather than creating a special syntax
for constructing a union, I decided that it was simplest to implement the
insertvalue instruction for a constant union expression:

    @foo = constant union { i32, float } insertvalue union { i32, float }
undef, i32 4, 0

What this says is to start with an undef, and then insert the value '4' into
the integer field (the zeroth field) of the union.

The reason for doing it this way is that to construct a union, you really
need 4 pieces of information: The type of the union, the type and value of
the member to be initialized, and the index of which member is being
initialized. Originally I thought about having the last be detected
automatically by what type of initializer was used:

    @foo = constant union { i32, float } i32 4

However, from a syntactical standpoint what you get is two types in a row -
"union { i32, float }" followed by "i32". That is completely unlike any
other IR syntax and doesn't fit well into the parser. Using insertvalue as
an initializer has the advantage that it's parameters supply all of
information we need. The disadvantage is that you have to type the union
type signature twice, but I doubt that will be a major issue since IR isn't
meant to be typed by hand anyway.

On Tue, Jan 12, 2010 at 5:01 PM, Talin <viridia at gmail.com> wrote:

> Here is the LangRef part of the patch.
>
>
> On Tue, Jan 12, 2010 at 2:11 PM, Chris Lattner <clattner at apple.com> wrote:
>
>>
>> On Jan 11, 2010, at 4:30 PM, Talin wrote:
>>
>>  I'm working on a new version of the patch.
>>>
>>> Another thing I wanted to ask about - do you prefer to have one giant
>>> patch that has everything, or a series of incremental patches? I can see
>>> advantages either way.
>>>
>>
>> A series of incremental patches is strongly preferred, starting with
>> LangRef.html.
>>
>>
>>  Normally I would want to do this as a series of incremental patches,
>>> however this is a rather large project and it may take me quite a while
>>> before it's completely done. I don't doubt that I will need some assistance
>>> when it comes to the trickier parts (like the optimization aspects you
>>> mentioned.) So there's a risk involved in submitting the first one or two
>>> patches, because the final patch might not be ready in time for the next
>>> release.
>>>
>>> On the other hand, it will be a lot easier for others to assist if we go
>>> ahead and submit the initial work.
>>>
>>
>> No problem, just submit it as you go.  When the langref piece goes in,
>> just say in it that this is an experimental feature in development.  Thanks
>> Talin,
>>
>> -Chris
>>
>>
>
>
> --
> -- Talin
>



-- 
-- Talin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20100114/1fd36eca/attachment.html>


More information about the llvm-dev mailing list