> So it will stack overflow on tail callsAt the moment, yes. But then again, so does java. Also, it looks like they're working on support for tail calls in the Da Vinci Machine[1].> and break with run-time errorsWhen I said it raises an assertion, I meant at compile-time.> on structs?No, structs are supported. The only unsupported types at the moment (as far as I am aware) are things like i31 and f80.> I would love to be able to evaluate LLVM IR in a safe environment (like the > JVM) for debugging purposes but this is too incomplete to be useful for me: > my IR depends heavily upon tail calls and value types. Unfortunately, the > MSIL backend and lli are also incomplete and, therefore, useless for me too. > > As Chris said, the LLVM world really needs any fully working solution rather > than a selection of incomplete solutions.I haven't been working on this project for too long - you can't expect it to be perfect on the first release. [1] http://openjdk.java.net/projects/mlvm/subprojects.html#TailCalls -- David Roberts http://da.vidr.cc/ On Sun, Nov 29, 2009 at 09:49, Jon Harrop <jon at ffconsultancy.com> wrote:> On Saturday 28 November 2009 06:20:39 David Roberts wrote: >> > How do you handle tail calls and value types? >> >> I haven't worried too much about optimisation yet, so it doesn't do >> anything special for tail calls (although neither does the java >> compiler). LLVM types are translated to their equivalent java >> primitive type (or currently it raises an assertion if there is no >> equivalent type). > > So it will stack overflow on tail calls and break with run-time errors on > structs? > > I would love to be able to evaluate LLVM IR in a safe environment (like the > JVM) for debugging purposes but this is too incomplete to be useful for me: > my IR depends heavily upon tail calls and value types. Unfortunately, the > MSIL backend and lli are also incomplete and, therefore, useless for me too. > > As Chris said, the LLVM world really needs any fully working solution rather > than a selection of incomplete solutions. > > -- > Dr Jon Harrop, Flying Frog Consultancy Ltd. > http://www.ffconsultancy.com/?e > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev >
Hi David,> No, structs are supported. The only unsupported types at the moment > (as far as I am aware) are things like i31 and f80.for funky sized integers, the most important operations to support are loads and stores, shifts and logical operations (and, or, xor). These are the ones that the optimizers like to introduce most. The logical operations are straightforward. Loads and stores of iN are equivalent to using memcpy of (N+7)/8 bytes from memory to wherever you are keeping the value (for a load), or the reverse for a store, so that's pretty easy as well [this assumes that you set things up right so that endianness is the same in memory and in "registers"]. Shifts are the most complicated, but still pretty simple. Ciao, Duncan.
On Sunday 29 November 2009 02:06:04 you wrote:> > So it will stack overflow on tail calls > > At the moment, yes. But then again, so does java.Sure but a lot of people like me are using LLVM precisely because it offers these wonderful features. As long as your JVM backend does not handle these features correctly its utility is greatly diminished.> Also, it looks like they're working on support for tail calls in the Da > Vinci Machine[1].I believe that work was actually finished some time ago by my hero, Arnold Schwaighofer, who was also responsible for the excellent TCO implementation in LLVM.> > and break with run-time errors > > When I said it raises an assertion, I meant at compile-time. > > > on structs? > > No, structs are supported. The only unsupported types at the moment > (as far as I am aware) are things like i31 and f80.How do you support structs when the JVM is incapable of expressing value types? Do you box every aggregate in an object? Does insertvalue construct an entirely new object? If so, the performance degradation will be orders of magnitude. Optimizing structs for the JVM is not easy and you will never get decent performance out of the JVM in the general case.> > As Chris said, the LLVM world really needs any fully working solution > > rather than a selection of incomplete solutions. > > I haven't been working on this project for too long - you can't expect > it to be perfect on the first release.Nobody is asking for perfection, just completeness. -- Dr Jon Harrop, Flying Frog Consultancy Ltd. http://www.ffconsultancy.com/?e
Hi Duncan,> for funky sized integers, the most important operations to support are > loads and stores, shifts and logical operations (and, or, xor). These > are the ones that the optimizers like to introduce most. The logical > operations are straightforward. Loads and stores of iN are equivalent > to using memcpy of (N+7)/8 bytes from memory to wherever you are keeping > the value (for a load), or the reverse for a store, so that's pretty easy > as well [this assumes that you set things up right so that endianness is > the same in memory and in "registers"]. Shifts are the most complicated, > but still pretty simple.Thanks for the tip :) - I'll look into adding support for these. -- David Roberts http://da.vidr.cc/ On Sun, Nov 29, 2009 at 20:06, Duncan Sands <baldrick at free.fr> wrote:> Hi David, > >> No, structs are supported. The only unsupported types at the moment >> (as far as I am aware) are things like i31 and f80. > > for funky sized integers, the most important operations to support are > loads and stores, shifts and logical operations (and, or, xor). These > are the ones that the optimizers like to introduce most. The logical > operations are straightforward. Loads and stores of iN are equivalent > to using memcpy of (N+7)/8 bytes from memory to wherever you are keeping > the value (for a load), or the reverse for a store, so that's pretty easy > as well [this assumes that you set things up right so that endianness is > the same in memory and in "registers"]. Shifts are the most complicated, > but still pretty simple. > > Ciao, > > Duncan. >
>> > So it will stack overflow on tail calls >> >> At the moment, yes. But then again, so does java. > > Sure but a lot of people like me are using LLVM precisely because it offers > these wonderful features. As long as your JVM backend does not handle these > features correctly its utility is greatly diminished.The issue is that current JVMs don't provide good support for tail calls. Self recursive functions could probably be optimised into loops, but apart from that I'm not sure what I can do. You're obviously much more familiar with TCO than I am, so perhaps you can suggest a solution.>> No, structs are supported. The only unsupported types at the moment >> (as far as I am aware) are things like i31 and f80. > > How do you support structs when the JVM is incapable of expressing value > types? Do you box every aggregate in an object? Does insertvalue construct an > entirely new object? If so, the performance degradation will be orders of > magnitude. Optimizing structs for the JVM is not easy and you will never get > decent performance out of the JVM in the general case.Oh, sorry, I see what you mean. No, first-class structs aren't supported.>> I haven't been working on this project for too long - you can't expect >> it to be perfect on the first release. > > Nobody is asking for perfection, just completeness.I'd just like to point out that I don't have a great deal of experience in compiler development - I just thought that this would be an interesting project to try. I realise that it isn't complete in it's current state. -- David Roberts http://da.vidr.cc/ On Mon, Nov 30, 2009 at 04:46, Jon Harrop <jon at ffconsultancy.com> wrote:> On Sunday 29 November 2009 02:06:04 you wrote: >> > So it will stack overflow on tail calls >> >> At the moment, yes. But then again, so does java. > > Sure but a lot of people like me are using LLVM precisely because it offers > these wonderful features. As long as your JVM backend does not handle these > features correctly its utility is greatly diminished. > >> Also, it looks like they're working on support for tail calls in the Da >> Vinci Machine[1]. > > I believe that work was actually finished some time ago by my hero, Arnold > Schwaighofer, who was also responsible for the excellent TCO implementation > in LLVM. > >> > and break with run-time errors >> >> When I said it raises an assertion, I meant at compile-time. >> >> > on structs? >> >> No, structs are supported. The only unsupported types at the moment >> (as far as I am aware) are things like i31 and f80. > > How do you support structs when the JVM is incapable of expressing value > types? Do you box every aggregate in an object? Does insertvalue construct an > entirely new object? If so, the performance degradation will be orders of > magnitude. Optimizing structs for the JVM is not easy and you will never get > decent performance out of the JVM in the general case. > >> > As Chris said, the LLVM world really needs any fully working solution >> > rather than a selection of incomplete solutions. >> >> I haven't been working on this project for too long - you can't expect >> it to be perfect on the first release. > > Nobody is asking for perfection, just completeness. > > -- > Dr Jon Harrop, Flying Frog Consultancy Ltd. > http://www.ffconsultancy.com/?e >
On Nov 29, 2009, at 10:46 AM, Jon Harrop wrote:>> >> No, structs are supported. The only unsupported types at the moment >> (as far as I am aware) are things like i31 and f80. > > How do you support structs when the JVM is incapable of expressing value > types? Do you box every aggregate in an object? Does insertvalue construct an > entirely new object? If so, the performance degradation will be orders of > magnitude. Optimizing structs for the JVM is not easy and you will never get > decent performance out of the JVM in the general case.First-class aggregate values can be supported in an environment like this by lowering each member of a struct into a separate variable. This is what LLVM's lib/CodeGen backends do, for example. Perhaps some of the code for that could be factored out into utility routines. Dan