[llvm-commits] RFC: initial union syntax support

[Duncan Sands]

Hi Andrew,

> This works in some cases, but I think the key consideration is how
> easy it is to reason about types and memory in analysis/optimizations.

I agree.  But notice that if you have no target data (so don't know
how big types are) then alias analysis and other optimizations are
going to have difficulty with union types.  For example, if you have
a union of two structs A and B, you can't tell whether writing to a
field of A changes the value you will read from a field of B.  And if
you do have target data then the union type wasn't that useful after
all.

>  All of these already have to handle zero-length struct elements,
> which meant almost nothing needed adjusting for unions.  A union type
> makes it very explicit what is going on.  Lists of sizes and
> alignments and bitcasts all over (even just to get said size and
> alignment (and this would require a constantExpr for alignof(type))
> seems to just be a lot of extra operations to express something that
> can be expressed very simply in an easy to understand way.

In spite of appearances I'm not totally against union types.  The
solution I suggested is certainly extremely ugly.  I think the main
thing I don't like about the union types suggestion (and this is
mainly psychological rather than rational) is that it smells a bit
like "here is something I have in C, so I want it in LLVM too!",
i.e. that people want unions because they are a familiar concept,
not necessarily because they are the right concept.

> The fact that bitcasts are equivalent to:
> %agg1 = insertvalue union {i32, float} %agg, i32 1, 0    ; yields
> union {i32, float}
> %result = extractvalue union {i32, float} %agg1, 1    ; yields float
> is an interesting side effect.  (and the one I am least happy about,
> though it could be cleaned up very simply).

In my opinion bitcast is a more fundamental and powerful concept than
union types, so I'd rather say that the problem is that union types
can often be eliminated in favour of a bitcast!  i.e. that this new
feature is not orthogonal to bitcasts.  It is a bit worrying, because
it suggests that the right concept has not been found.  On the other
hand, it's also normal that in simple cases things can be done more
than one way.

Ciao,

Duncan.