On Jan 1, 2009, at 6:25 AM, Jon Harrop wrote:>> Exactly. I'm not especially interested in C-style unions, I'm >> interested >> in discriminated unions. But the actual discriminator field is easily >> represented in LLVM IR already, so there's no need to extend the IR >> to >> support them. That's why I am only asking for C-style union support - >> it's a lower-level primitive that you can use to build discriminated >> unions on top of. > > I don't think you would want to build discriminated unions on top of > C-style > unions though.Why?>> The problem with varying-size structs is that it would be nice to be >> able to pass them as function parameters and function return values >> using LLVM's support of structs as first-class data types. > > As I understand it, LLVM does not provide first-class structs and > attempting > to return arbitrary structs from functions will randomly break. I > believe you > need to implement that yourself in whatever way your target language > requires.This is a current implementation deficiency, not a design limitation. We welcome patches to fix this. -Chris
On Friday 02 January 2009 20:48:25 Chris Lattner wrote:> On Jan 1, 2009, at 6:25 AM, Jon Harrop wrote: > >> Exactly. I'm not especially interested in C-style unions, I'm > >> interested in discriminated unions. But the actual discriminator field is > >> easily represented in LLVM IR already, so there's no need to extend the > >> IR to support them. That's why I am only asking for C-style union > >> support - it's a lower-level primitive that you can use to build > >> discriminated unions on top of. > > > > I don't think you would want to build discriminated unions on top of > > C-style unions though. > > Why?Uniformity when nesting and space efficiency. Users of a language front-end will want to nest discriminated unions, e.g. to manipulate trees. C-style unions are designed to be unboxed so they are useless for that unless you introduce pointer indirections but if you store all unions by reference then the uniformity of the 1-word pointer size obviates the need to use same (largest) size union cases so you would drop C-style unions in favor of a more space-efficient alternative anyway. Otherwise, you might opt for a non-uniform representation where local unions are unboxed but unions stored within them are boxed, which is needless complexity but it might buy a little performance. So I think most LLVM users will represent their discriminated unions as something like: {i32, {..} *} or: {i32, {..}} * but not as C-style unions. -- Dr Jon Harrop, Flying Frog Consultancy Ltd. http://www.ffconsultancy.com/?e
On Jan 2, 2009, at 2:29 PM, Jon Harrop wrote:>>> I don't think you would want to build discriminated unions on top of >>> C-style unions though. >> >> Why? > > Uniformity when nesting and space efficiency. Users of a language > front-end > will want to nest discriminated unions, e.g. to manipulate trees.Okay, so you're just talking about boxed vs unboxed discriminated unions, or "by ref" vs "by value" discriminated unions. Clearly the LLVM IR support for "c style unions" would only be useful for "unboxed" or "byvalue" discriminated unions. That doesn't mean that *your* specific uses would need them. If you're doing "by-ref" or "boxed" unions, then our current support should already be sufficient. -Chris