Hi,> but haven't had time (or machines) to do further development. I would > love to see someone add 64-bit ABI and JIT support. I don't know ofAnd fix 32 bit ones :) Mostly byval stuff + FP arguments. -- With best regards, Anton Korobeynikov Faculty of Mathematics and Mechanics, Saint Petersburg State University
On Tue, 11 Nov 2008, Anton Korobeynikov wrote:> Hi, > >> but haven't had time (or machines) to do further development. I would >> love to see someone add 64-bit ABI and JIT support. I don't know of > > And fix 32 bit ones :) Mostly byval stuff + FP arguments.It looks like I'm going to be working on the 32-bit stuff periodically over the next couple of months so that I can run tests on the Niagara (and soon Rock) processors. Luke
Anton Korobeynikov wrote:> And fix 32 bit ones :) Mostly byval stuff + FP arguments.How serious these bugs are? Any link to bug descriptions? Is LLVM sparc target usable and stable in case of not using any FP stuff? -- Best Regards Peter Shugalev
On Tue, 11 Nov 2008, Peter Shugalev wrote:> Anton Korobeynikov wrote: >> And fix 32 bit ones :) Mostly byval stuff + FP arguments. > > How serious these bugs are? Any link to bug descriptions? Is LLVM sparc > target usable and stable in case of not using any FP stuff? >There are usually two levels of translation that go on. First, your C/C++ code is compiled to LLVM IR using llvm-gcc. Then, LLVM generates SPARC assembly from the LLVM IR. llvm-gcc isn't prepared to compile for a SPARC target. This includes lack of complete FP support, and no implementation of the SPARC ABI which means that function arguments aren't passed correctly and you probably can't call any precompiled code that assumes the SPARC ABI. I will be working on fixing this for sparc-solaris, but not sparc64. LLVM code generation doesn't appear to correctly implement atomic builtins, but that should be a trivial thing to fix (so they tell me). -Luke