similar to: [LLVMdev] Union type, is it really used or necessary?

On Tue, Jul 20, 2010 at 2:46 PM, Talin <viridia at gmail.com> wrote: > On Tue, Jul 20, 2010 at 8:34 AM, Chris Lattner <clattner at apple.com> wrote: > >> >> On Jul 20, 2010, at 1:36 AM, Anton Korobeynikov wrote: >> >> >> used to make the code manipulating the union type "well typed". This >> >> approach seems work very well, is

On Tue, Jul 20, 2010 at 8:34 AM, Chris Lattner <clattner at apple.com> wrote: > > On Jul 20, 2010, at 1:36 AM, Anton Korobeynikov wrote: > > >> used to make the code manipulating the union type "well typed". This > >> approach seems work very well, is there really a need to keep union type > in > >> LLVM? > > I think in its current

On Jul 20, 2010, at 1:36 AM, Anton Korobeynikov wrote: >> used to make the code manipulating the union type "well typed". This >> approach seems work very well, is there really a need to keep union type in >> LLVM? > I think in its current state the unions should be removed from LLVM IR > in next release. It's pretty much unfinished and noone is willing to

> used to make the code manipulating the union type "well typed". This > approach seems work very well, is there really a need to keep union type in > LLVM? I think in its current state the unions should be removed from LLVM IR in next release. It's pretty much unfinished and noone is willing to work on them. > Is there a front-end emitting union type? Not that I'm

I removed unions from mainline in r112356. -Chris On Jul 20, 2010, at 2:46 PM, Talin wrote: > On Tue, Jul 20, 2010 at 8:34 AM, Chris Lattner <clattner at apple.com> wrote: > > On Jul 20, 2010, at 1:36 AM, Anton Korobeynikov wrote: > > >> used to make the code manipulating the union type "well typed". This > >> approach seems work very well, is

On Sep 7, 2010, at 6:22 AM, Erik de Castro Lopo wrote: > > I'm currently use llvm-2.7 and have been using unions, not being > aware that they are going to be removed. The use case is for > forcing field alignments in a packed struct to be correct for > 32 and 64 bits. In particular I have a struct with an i32 tag > field followed by a pointer. > > When generating 32

Here's a suggestion - can we make the "union patch" (the inverse of the patch that removed unions) as a downloadable file so that people who are interested in finishing the work can do so? On Tue, Sep 7, 2010 at 7:55 AM, Renato Golin <rengolin at systemcall.org>wrote: > On 7 September 2010 15:36, Anton Korobeynikov <anton at korobeynikov.info> > wrote: > >

Chris Lattner wrote: > I removed unions from mainline in r112356. Sorry for reviving this old thread, but I think the removal of unions is a real pity. I use Haskell to generate LLVM code using David Terei's LLVM code from the GHC compiler (the compiler I'm working on is also written in Haskell). Once I've generated LLVM IR code I use llc to generate object code. I'm

On 7 September 2010 15:36, Anton Korobeynikov <anton at korobeynikov.info> wrote: > Otherwise the feature being unused will quickly became broken. It was already broken for ages... :/ Even if you're not using the backends (or MC), having it in front-end only will only confuse new users that will try to use it and hope it just works (my case, a few months ago). If there is nothing,

Eli Friedman wrote: > On Tue, Sep 7, 2010 at 8:16 AM, Talin <viridia at gmail.com> wrote: > > Here's a suggestion - can we make the "union patch" (the inverse of the > > patch that removed unions) as a downloadable file so that people who are > > interested in finishing the work can do so? > > Anyone who's really interested in working on it can

Dan Gohman wrote: > If you want to make sure the pointer field is properly aligned, why not > just use a non-packed struct: { i32, pointer } ? Or if you really want > a packed struct, can you use <{ i32, i32, pointer }>, since you're > already emitting target-dependent IR anyway? > > If you're computing the offset in order to use as a value > within the

On Tue, Sep 7, 2010 at 8:16 AM, Talin <viridia at gmail.com> wrote: > Here's a suggestion - can we make the "union patch" (the inverse of the > patch that removed unions) as a downloadable file so that people who are > interested in finishing the work can do so? Anyone who's really interested in working on it can just use "svn diff -c 112356", and apply

David Given wrote: > On 07/09/10 14:22, Erik de Castro Lopo wrote: > [...] > > When generating 32 bit code the struct looks like: > > > > <{ i32, pointer }> > > > > and for 64 bit code: > > > > <{ union { i32, i64 }, pointer }> > > Surely LLVM will cause the first structure to be correctly aligned on > 64-bit

On 07/09/10 14:22, Erik de Castro Lopo wrote: [...] > When generating 32 bit code the struct looks like: > > <{ i32, pointer }> > > and for 64 bit code: > > <{ union { i32, i64 }, pointer }> Surely LLVM will cause the first structure to be correctly aligned on 64-bit platforms by automatically inserting padding? Is explicit alignment by the user

Hello, Erik > Otherwise, I'd like to know what needs to be done to get unions > back in LLVM. Well, the answer is pretty easy: someone should "fix" them to be supported throughout the whole set of libraries and became a "maintainer". Otherwise the feature being unused will quickly became broken. -- With best regards, Anton Korobeynikov Faculty of Mathematics and

Chris Lattner wrote: > > a) What is required for them to be accepted back in? > > It needs to work. When reverted, it was broken in almost all cases. 'It needs work' and 'it was broken' doesn't really give me an idea of what specifically is required. Specifically, what I am interested in is using unions within packed structs to force alignment. Using unions

On Sep 7, 2010, at 2:24 PM, Erik de Castro Lopo wrote: > Eli Friedman wrote: > >> On Tue, Sep 7, 2010 at 8:16 AM, Talin <viridia at gmail.com> wrote: >>> Here's a suggestion - can we make the "union patch" (the inverse of the >>> patch that removed unions) as a downloadable file so that people who are >>> interested in finishing the work

On 08 Sep 2010, at 13:03, David Given wrote: > On 07/09/10 14:22, Erik de Castro Lopo wrote: > [...] >> When generating 32 bit code the struct looks like: >> >> <{ i32, pointer }> >> >> and for 64 bit code: >> >> <{ union { i32, i64 }, pointer }> > > Surely LLVM will cause the first structure to be correctly aligned on >

On Tue, Jul 20, 2010 at 2:46 PM, Talin <viridia at gmail.com> wrote: > 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 >

On 01/15/2010 11:37 AM, Talin wrote: > Yes, that's closer to the frontend semantics: the variants of a > union type don't have any natural ordering, so list semantics could > cause problems. I agree. I probably shouldn't even comment, as I know so little about LLVM. But I've hand-written a couple kLOC of IR now and am starting to get a feel for the