Union type efforts and ComputeLinearIndex

I am curious how the efforts were progressing in implementing a union type. I am will to try to contribute somewhat to this even though I am perhaps somewhat of a beginner with LLVM(so it might be nice to collaborate with someone). I had a look at some of the subsystems that would require changes though I may have missed some.

I however have a few questions-

1) What is ComputeLinearIndex for specifically? I would expect that perhaps the RTTI stuff in there might need to support a new case for a union type.

2) The subsystems I have catalogued that probably need patching are AsmParser, BitCode(Reader/Writer), Target, CodeGen and some stuff in VMCore. Did I miss anything?

Thanks in advance.

Hello,

My understanding of the discussions about union types was that
there was trouble working out how unions should work. Have
the issues been resolved? If so, could you post a summary?

Thanks,

Dan

Hi,

I really dont know I came rather late to the discussion and some kind folks on this list gave me a few links. I didnt see much mention of any controversy. Are there issues still that need to be resolved?

So far I am still quite the novice with LLVM internals but looking over the code it looks like one could hack in most of the required functionality up to the DAG building stage. I am not sure if this would work so perhaps I could get some opinions.

My thoughts were as follows- introduce a new CompositeType called union (possibly refactoring some stuff into a common parent class from StructType).

Recycle GEP (using RTTI) to handle UnionType field lookups as well. Add type codes into bitreader/bitwriter which would cope with the new union type. Add u { ... } into the AsmParser.

Revise some of the target classes to cope with the unusual data layout and report back correct size for the union type. Add support for DAG generation into the DAGBuilder visitor class.

I am just seeing this UnionType as a type of struct where all the fields have the same offset and the UnionType itself is as large as the largest member. I would speculate that otherwise it behaves pretty much like a StructType- but then again I am new to LLVM.

I posted an initial implementation that would generate code correctly,
though I don't know that all optimization pass were safe still.

see:

http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20090511/077443.html

As far as I know, there isn't enough demand right now for unions.
They are mainly useful for target-independent front-ends. I don't
have the time right now to push them, though they would be useful for
my work, just not critical.

Andrew

I just looked over your diff and it would seem to me that additional changes would be needed to be done to some of the LLVM-IR -> DAG stuff to make things fully functional (this could be a bit of supposition on my part since I do not fully understand all of the code).

I just looked over your diff and it would seem to me that additional changes would be needed to be done to some of the LLVM-IR -> DAG stuff to make things fully functional (this could be a bit of supposition on my part since I do not fully understand all of the code).

Code generation actually was supported.

See:
http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20090511/077465.html

Namely, look at the code in target data.

Andrew

Ah alright you more or less implemented (perhaps with slight differences) what I was thinking as well.

Stepping back for a moment, what do you need unions for? One thing
to consider is that you may not actually need a union type. Take a
look at how current C front-ends implement C union types in LLVM IR,
for example. LLVM IR is very permissive about pointers, in general, so
you can do a lot of uniony things without needing formal union types.

BTW, to answer your original question, ComputeLinearIndex and the
code that uses it is there to handle first-class struct values. It does
so by splitting the members of a struct into separate variables.
This wouldn't work for a union, so you'd need to come up with a
different approach, such as stuffing unions in memory in order to
do inserts or extracts. Alternatively, you could disallow first-class
unions altogether, but then structs containing unions wouldn't
be first-class, which would be an awkward special case.

So, there are some wrinkles involved. And this motivates the
questions of what unions are actually needed for, and what the
best way to provide any needed functionality is.

Dan

Hi,

I really dont know I came rather late to the discussion and some kind folks on this list gave me a few links. I didnt see much mention of any controversy. Are there issues still that need to be resolved?

So far I am still quite the novice with LLVM internals but looking over the code it looks like one could hack in most of the required functionality up to the DAG building stage. I am not sure if this would work so perhaps I could get some opinions.

My thoughts were as follows- introduce a new CompositeType called union (possibly refactoring some stuff into a common parent class from StructType).

Recycle GEP (using RTTI) to handle UnionType field lookups as well. Add type codes into bitreader/bitwriter which would cope with the new union type. Add u { ... } into the AsmParser.

Revise some of the target classes to cope with the unusual data layout and report back correct size for the union type. Add support for DAG generation into the DAGBuilder visitor class.

I am just seeing this UnionType as a type of struct where all the fields have the same offset and the UnionType itself is as large as the largest member. I would speculate that otherwise it behaves pretty much like a StructType- but then again I am new to LLVM.

Dan