<br><br><div class="gmail_quote">On Tue, Jul 20, 2010 at 2:46 PM, Talin <span dir="ltr"><<a href="mailto:viridia@gmail.com">viridia@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div><div></div><div class="h5">On Tue, Jul 20, 2010 at 8:34 AM, Chris Lattner <span dir="ltr"><<a href="mailto:clattner@apple.com" target="_blank">clattner@apple.com</a>></span> wrote:<br></div></div><div class="gmail_quote">
<div><div></div><div class="h5"><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">

<div><br>
On Jul 20, 2010, at 1:36 AM, Anton Korobeynikov wrote:<br>
<br>
>> used to make the code manipulating the union type "well typed". This<br>
>> approach seems work very well, is there really a need to keep union type in<br>
>> LLVM?<br>
> I think in its current state the unions should be removed from LLVM IR<br>
> in next release. It's pretty much unfinished and noone is willing to<br>
> work on them.<br>
<br>
</div>I agree.<br>
<font color="#888888"><br></font></blockquote></div></div><div>Unfortunately I wasn't able to take the union stuff much farther than I did. Partly that was because my LLVM-related work has been on hiatus for the last 4 months or so due to various issues going on in my personal life. But it was also partly because I had reached the limit of my knowledge in this area, I wasn't able to delve deeply enough into the code generation side of LLVM to really understand what needed to be done to support unions.</div>


<div><br></div><div>As far as converting a union into a C struct that is large enough to hold all possible types of the union, there are two minor problems associated with this approach:</div><div><br></div><div>1) For frontends that generate target-agnostic code, it is difficult to calculate how large this struct should be. (Which is larger, 3 int32s or two pointers? You don't know unless your frontend knows the size of a pointer.) In my case, I finally decided to abandon my goal of making my frontend completely target-neutral. While it's relatively easy to write a frontend that is 99% target-neutral with LLVM, that last 1% cannot be eliminated.</div>
</div></blockquote><div> </div><div>This is indeed a problem if a front-end or any pass has to compute the size of a type.  For example, Sometimes I need to find out the size of a type in my pass, I then call TargetData.getTypeStorageSize() to get the size of a particular type.  This practice will introduce architecture-dependent LLVM code.  IMHO, LLVM cannot avoid this problem anyway, unless such function is removed or returns a ConstantExpr.  Probably, LLVM has a function that returns a ConstantExpr type size, I'm just ignorant in this aspect. <br>
<br>Another thought is can you delay the computing of the maximum storage of a union type by using a max operator?  <br>Your example can be represented as "struct { max([3xi32], [2xi8*],...) }", this approach will avoid deciding the size in front-ends. But again allowing TargetData.getTypeStorageSize() can compromise the architecture-neutrality goal. <br>
 <br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div class="gmail_quote">

<div><br></div><div>2) Extracting the values from the union require pointer casting, which means that the union cannot be an SSA value - it has to have an address. This probably isn't a big issue in languages like C++ which use unions infrequently, but other languages which use algebraic type systems might suffer a loss of performance due to the need to store union types in memory.</div>
</div></blockquote><div>Can mem2reg alleviate  this problem? <br><br>Cheers,<br>Neal<br></div></div><br>