>> > 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 >
2009/11/30 David Roberts <d at vidr.cc>:>> 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.Hi David and Jon, After reading this thread, I think there has been a slight misunderstanding. I agree with Jon that there are some crucial problems with your patch re odd size variables and tail calls (possibly many other issues that were overlooked), but I also agree with David that, as this is an experiment, it's not perfect, nor complete. If you apply that as a patch now, everyone else will have to maintain it when they do their unrelated changes, increasing the cost of the project's maintenance. I welcome your code (have been wondering about it recently too), but I think that you should keep it as a separate project for now. Once it's at least complete, I'm sure people will be happy to apply as a patch, but for now it'll be more nuisance than help. Just to give you some figures, I've written a very simple compiler using LLVM with less than 10 classes using mostly the IR codegen, some function passes and the JIT. It was common for me to have to update my own code twice in the same day for changes in the internal libraries. I was happy to do so, but I believe that if I ever merged my code to mainstream, every single one of them would have to change my code as well before committing. Once it's complete, check in. Once it's perfect, get a Nobel prize. ;) My tuppence... cheers, --renato Reclaim your digital rights, eliminate DRM, learn more at http://www.defectivebydesign.org/what_is_drm
> If you apply that as a patch now, everyone else will have to maintain > it when they do their unrelated changes, increasing the cost of the > project's maintenance. I welcome your code (have been wondering about > it recently too), but I think that you should keep it as a separate > project for now. Once it's at least complete, I'm sure people will be > happy to apply as a patch, but for now it'll be more nuisance than > help.I hope I didn't give the impression that I was pushing to get this commited - I'm quite happy to keep it as a separate project. I've cleaned up the code a bit and released it as part of LLJVM[1], so any fixes to the problems people have highlighted in this thread will be pushed to the repository listed on that page as I get to them. [1] http://da.vidr.cc/projects/lljvm/ -- David Roberts http://da.vidr.cc/ On Mon, Nov 30, 2009 at 19:39, Renato Golin <rengolin at systemcall.org> wrote:> 2009/11/30 David Roberts <d at vidr.cc>: >>> 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. > > Hi David and Jon, > > After reading this thread, I think there has been a slight misunderstanding. > > I agree with Jon that there are some crucial problems with your patch > re odd size variables and tail calls (possibly many other issues that > were overlooked), but I also agree with David that, as this is an > experiment, it's not perfect, nor complete. > > If you apply that as a patch now, everyone else will have to maintain > it when they do their unrelated changes, increasing the cost of the > project's maintenance. I welcome your code (have been wondering about > it recently too), but I think that you should keep it as a separate > project for now. Once it's at least complete, I'm sure people will be > happy to apply as a patch, but for now it'll be more nuisance than > help. > > Just to give you some figures, I've written a very simple compiler > using LLVM with less than 10 classes using mostly the IR codegen, some > function passes and the JIT. It was common for me to have to update my > own code twice in the same day for changes in the internal libraries. > I was happy to do so, but I believe that if I ever merged my code to > mainstream, every single one of them would have to change my code as > well before committing. > > Once it's complete, check in. Once it's perfect, get a Nobel prize. ;) > > My tuppence... > > cheers, > --renato > > Reclaim your digital rights, eliminate DRM, learn more at > http://www.defectivebydesign.org/what_is_drm >