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.
--- On Sun, 8/2/09, Dan Gohman <gohman at apple.com> wrote:
> From: Dan Gohman <gohman at apple.com>
> Subject: Re: [LLVMdev] Union type efforts and ComputeLinearIndex
> To: "LLVM Developers Mailing List" <llvmdev at cs.uiuc.edu>
> Date: Sunday, August 2, 2009, 12:05 PM
> 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
>
> On Aug 2, 2009, at 7:45 AM, Carter Cheng wrote:
>
> > 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.
> >
> >
> >
> > _______________________________________________
> > LLVM Developers mailing list
> > LLVMdev at cs.uiuc.edu
> http://llvm.cs.uiuc.edu
> > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu
> http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>
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 On Sun, Aug 2, 2009 at 3:57 PM, Carter Cheng<carter_cheng at yahoo.com> wrote:> 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. > > > --- On Sun, 8/2/09, Dan Gohman <gohman at apple.com> wrote: > >> From: Dan Gohman <gohman at apple.com> >> Subject: Re: [LLVMdev] Union type efforts and ComputeLinearIndex >> To: "LLVM Developers Mailing List" <llvmdev at cs.uiuc.edu> >> Date: Sunday, August 2, 2009, 12:05 PM >> 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 >> >> On Aug 2, 2009, at 7:45 AM, Carter Cheng wrote: >> >> > 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. >> > >> > >> > >> > _______________________________________________ >> > LLVM Developers mailing list >> > LLVMdev at cs.uiuc.edu >> http://llvm.cs.uiuc.edu >> > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev >> >> _______________________________________________ >> LLVM Developers mailing list >> LLVMdev at cs.uiuc.edu >> http://llvm.cs.uiuc.edu >> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev >> > > > > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev >
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). --- On Sun, 8/2/09, Andrew Lenharth <andrewl at lenharth.org> wrote:> From: Andrew Lenharth <andrewl at lenharth.org> > Subject: Re: [LLVMdev] Union type efforts and ComputeLinearIndex > To: "LLVM Developers Mailing List" <llvmdev at cs.uiuc.edu> > Date: Sunday, August 2, 2009, 3:55 PM > 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 > > On Sun, Aug 2, 2009 at 3:57 PM, Carter Cheng<carter_cheng at yahoo.com> > wrote: > > 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. > > > > > > --- On Sun, 8/2/09, Dan Gohman <gohman at apple.com> > wrote: > > > >> From: Dan Gohman <gohman at apple.com> > >> Subject: Re: [LLVMdev] Union type efforts and > ComputeLinearIndex > >> To: "LLVM Developers Mailing List" <llvmdev at cs.uiuc.edu> > >> Date: Sunday, August 2, 2009, 12:05 PM > >> 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 > >> > >> On Aug 2, 2009, at 7:45 AM, Carter Cheng wrote: > >> > >> > 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. > >> > > >> > > >> > > >> > > _______________________________________________ > >> > LLVM Developers mailing list > >> > LLVMdev at cs.uiuc.edu > >> http://llvm.cs.uiuc.edu > >> > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > >> > >> _______________________________________________ > >> LLVM Developers mailing list > >> LLVMdev at cs.uiuc.edu > >> http://llvm.cs.uiuc.edu > >> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > >> > > > > > > > > > > _______________________________________________ > > LLVM Developers mailing list > > LLVMdev at cs.uiuc.edu > http://llvm.cs.uiuc.edu > > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > > > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu > http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev >
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 On Aug 2, 2009, at 1:57 PM, Carter Cheng wrote:> 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> > > --- On Sun, 8/2/09, Dan Gohman <gohman at apple.com> wrote: > > >> From: Dan Gohman <gohman at apple.com> >> >> Subject: Re: [LLVMdev] Union type efforts and ComputeLinearIndex >> >> To: "LLVM Developers Mailing List" <llvmdev at cs.uiuc.edu> >> >> Date: Sunday, August 2, 2009, 12:05 PM >> >> 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 >> >> >> >> On Aug 2, 2009, at 7:45 AM, Carter Cheng wrote: >> >> >> >>> 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. >>> >>> >>> >>> >>> >>> >>> >>> _______________________________________________ >>> >>> LLVM Developers mailing list >>> >>> LLVMdev at cs.uiuc.edu >>> >> http://llvm.cs.uiuc.edu >> >>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev >>> >> >> >> _______________________________________________ >> >> LLVM Developers mailing list >> >> LLVMdev at cs.uiuc.edu >> >> http://llvm.cs.uiuc.edu >> >> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev >> >> >> > > > > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev >
Maybe Matching Threads
- [LLVMdev] Union type efforts and ComputeLinearIndex
- [LLVMdev] Union type efforts and ComputeLinearIndex
- [LLVMdev] Union type efforts and ComputeLinearIndex
- [LLVMdev] Union type efforts and ComputeLinearIndex
- [LLVMdev] Union type efforts and ComputeLinearIndex