Union types

Project Infrastructure LLVM Dev List Archives
1

Hi All,

I've noticed the union type in the language manual [1] but it seems
it's not used too much.

According to the manual, the code:
union {
  int a;
  double b;
} a;

Could be compiled to:
%union.anon = type union { i32, double }

@a = common global %union.anon zeroinitializer, align 8 ;
<%union.anon*> [#uses=0]

But when I try to assemble it, I get:

$ llvm-as union.ll
llvm-as: Constants.cpp:67: static llvm::Constant*
llvm::Constant::getNullValue(const llvm::Type*): Assertion `!"Cannot
create a null constant of that type!"' failed.

The comment just above that line is:
default:
   // Function, Label, or Opaque type?

Which implies no one was expecting a UnionType there...

Also, if I generate the object code directly, llc fails too...

Is there any plan to implement the union type? The work-around is quite ugly...

cheers,
--renato

[1] http://llvm.org/docs/LangRef.html#t_union

2

Is there any plan to implement the union type? The work-around is quite ugly...

I don't think you can expect to see some robust support for unions
anytime soon.
Given its overall status I think it even might be dropped somewhere near 2.8

3

Really? I saw some progress on UnionTypes this year (Tim, Talin), is
there any reason to drop support for it?

Given that the current alternative route (dynamic struct types,
memcpy, static initialization for local variables) is horrible, is
there any plans on making the support for unions less painful?

cheers,
--renato

4

Sorry to Renato for getting two copeis of this, I cocked up the reply
first time.

Anyway, here's a patch for this issue (I'd not tried zero initialiser
during my work). It seems to pass all the same tests as llvm did before,
and give reasonable output.

Also, does anyone know off the top of their heads what would be needed
to get unions up to scratch? They do seem to be a neat solution and I'd
be sad to see them removed.

Tim.

zeroInit.patch (886 Bytes)

5

Hi All,

Which implies no one was expecting a UnionType there...

Also, if I generate the object code directly, llc fails too...

Is there any plan to implement the union type? The work-around is quite ugly...

Sorry to Renato for getting two copeis of this, I cocked up the reply
first time.

Anyway, here's a patch for this issue (I'd not tried zero initialiser
during my work). It seems to pass all the same tests as llvm did before,
and give reasonable output.

Thanks Tim, applied with a testcase here:
http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20100329/098758.html

Also, does anyone know off the top of their heads what would be needed
to get unions up to scratch? They do seem to be a neat solution and I'd
be sad to see them removed.

I don't think that anyone is really using them yet, which means that they probably have lots of little bugs like this.

-Chris

6

Last time I looked at the union stuff, I was trying to decide how to implement TargetData.cpp for unions, and whether or not to copy the way structs handled memory layout. Currently structs have an auxilliary data structure (StructLayout) that is used to cache the overall size of the struct and the offset of each member. In the case of unions, it doesn’t need the offsets, since they are always zero, but it does need to calculate the overall size (with alignment considerations). The alternative is to simply recalculate the union size each time it is needed – it does seem like a lot of extra complexity to have a whole cache just for the size.

At the moment, my LLVM-related project is on hiatus - After two years of working on it I decided to take a few months off to recharge my creative batteries before tackling the next phase (which is garbage collection - I did make pretty good progress generating the tables for direct probing of stack roots, without needing shadow-stack.)

7

Hi Talin,

As a first implementation it doesn't seem like too much to recalculate
the union size every time, usually unions have less than a few dozen
fields, anyway.

I don't know how the lowering do the struct (and I'm on holiday now,
so hard to check), but an extra method on UnionType (or whatever
reflects on the lowering code) seems simple enough to return the size,
calculated on the c-tor or dynamically, via getPrimitiveSizeInBits()
method on each field.

cheers,
--renato

Reclaim your digital rights, eliminate DRM, learn more at
http://www.defectivebydesign.org/what_is_drm

8

BTW, I don’t know if I mentioned this but thank you for the patch. Do you know if you will be doing any further work on unions? I’m trying to decide / understand what to work on next - unfortunately I’m not all that familiar with the LLVM backends and code generators, I’m mostly a front end guy. :slight_smile: