On Feb 24, 2009, at 2:50 AM, Jon Harrop wrote:> On Monday 23 February 2009 16:14:57 Arnold Schwaighofer wrote: >> >> >> So the current situation is that tail calls on functions that >> return a >> struct are not optimized (as you correctly observed ;). Sorry. > > Thanks for the clarification. That makes a lot more sense! > > LLVM's support for structs is wonderful but I don't think they can be > called "first-class structs" until all such arbitrary restrictions > have been > removed, even though the workaround (using sret form) is trivial in > this > case."first-class" in this context means "Values can have this type", not "everything that anyone might want is supported in all backends." A meta issue is that LLVM IR differs from many virtual machine ISAs in that it's more of a language for expressing programs than a specification of what some particular machine can actually execute. When a particular LLVM component doesn't support a particular aspect of the language, it's considered a bug in the component, and not necessarily considered a problem in the language. This arrangement is convenient for people developing LLVM itself, because new language features can be added without the requirement that all backends and execution engines support all features in full generality, which isn't always immediately useful, and sometimes not even meaningful. However, it's inconvenient for people using LLVM, because there's no complete list of which features are actually supported on any given backend. Some features that are commonly unsupported are now mentioned LangRef.html, though it's certainly not complete. One way this issue might be addressed is with an LLVM IR conformance test suite. Covering the whole language would be a big project, but the work could be done incrementally. I wonder if people would be interested in working on this.> Shall I file this as a bug against LLVM?Yes, thanks. Dan
On Tuesday 24 February 2009 20:05:52 Dan Gohman wrote:> "first-class" in this context means "Values can have this type", not > "everything that anyone might want is supported in all backends."Ok.> A meta issue is that LLVM IR differs from many virtual machine ISAs in > that it's more of a language for expressing programs than a > specification of what some particular machine can actually execute. When a > particular LLVM component doesn't support a particular aspect of the > language, it's considered a bug in the component, and not necessarily > considered a problem in the language.Right.> This arrangement is convenient for people developing LLVM itself, > because new language features can be added without the requirement > that all backends and execution engines support all features in full > generality, which isn't always immediately useful, and sometimes not > even meaningful. However, it's inconvenient for people using LLVM, > because there's no complete list of which features are actually > supported on any given backend. Some features that are commonly > unsupported are now mentioned LangRef.html, though it's certainly > not complete.I think it would be extremely useful to document what exactly does not work and where these unwanted interactions occur in way that makes it as easy as possible for people to reference, so they can forsee bumps before they start building upon anything. I read other people's tales of woe with regard to some of LLVM's experimental features and learned to avoid them early on. This is one of the only minor niggles I've discovered myself. Once I have my own basic functionality up and running I'd like to move on to the more experimental stuff because it holds so much promise.> One way this issue might be addressed is with an LLVM IR > conformance test suite. Covering the whole language would be a > big project, but the work could be done incrementally. I wonder if > people would be interested in working on this.I would value other work a lot more, such as filling out the C bindings.> > Shall I file this as a bug against LLVM? > > Yes, thanks.Will do. -- Dr Jon Harrop, Flying Frog Consultancy Ltd. http://www.ffconsultancy.com/?e
On Wednesday 25 February 2009 00:06:23 Jon Harrop wrote:> On Tuesday 24 February 2009 20:05:52 Dan Gohman wrote: > > > Shall I file this as a bug against LLVM? > > > > Yes, thanks. > > Will do.This is #3664: http://llvm.org/bugs/show_bug.cgi?id=3664 -- Dr Jon Harrop, Flying Frog Consultancy Ltd. http://www.ffconsultancy.com/?e