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
http://systemcall.org/
[1] http://llvm.org/docs/LangRef.html#t_union
> 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 -- With best regards, Anton Korobeynikov Faculty of Mathematics and Mechanics, Saint Petersburg State University
On 29 March 2010 13:52, Anton Korobeynikov <anton at korobeynikov.info> wrote:> Given its overall status I think it even might be dropped somewhere near 2.8Really? 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
On Mon, Mar 29, 2010 at 01:15:30PM +0100, Renato Golin wrote:> 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. 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. -------------- next part -------------- Index: lib/VMCore/Constants.cpp ==================================================================--- lib/VMCore/Constants.cpp (revision 99809) +++ lib/VMCore/Constants.cpp (working copy) @@ -59,6 +59,7 @@ case Type::PointerTyID: return ConstantPointerNull::get(cast<PointerType>(Ty)); case Type::StructTyID: + case Type::UnionTyID: case Type::ArrayTyID: case Type::VectorTyID: return ConstantAggregateZero::get(Ty); @@ -944,7 +945,8 @@ // Factory Function Implementation ConstantAggregateZero* ConstantAggregateZero::get(const Type* Ty) { - assert((Ty->isStructTy() || Ty->isArrayTy() || Ty->isVectorTy()) && + assert((Ty->isStructTy() || Ty->isUnionTy() + || Ty->isArrayTy() || Ty->isVectorTy()) && "Cannot create an aggregate zero of non-aggregate type!"); LLVMContextImpl *pImpl = Ty->getContext().pImpl;
On Mar 29, 2010, at 7:15 AM, Tim Northover wrote:> On Mon, Mar 29, 2010 at 01:15:30PM +0100, Renato Golin wrote: >> 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
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.) On Mon, Mar 29, 2010 at 7:15 AM, Tim Northover <T.P.Northover at sms.ed.ac.uk>wrote:> On Mon, Mar 29, 2010 at 01:15:30PM +0100, Renato Golin wrote: > > 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. > > 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. > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > >-- -- Talin -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20100407/8fcd0fb9/attachment.html>
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. :) On Mon, Mar 29, 2010 at 7:15 AM, Tim Northover <T.P.Northover at sms.ed.ac.uk>wrote:> On Mon, Mar 29, 2010 at 01:15:30PM +0100, Renato Golin wrote: > > 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. > > 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. > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > >-- -- Talin -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20100430/bb2d8906/attachment.html>