>> Additional patch attached, is this suitable? > Looks good, thanks. What's about arithmetics?Revised patch attached. -- David Roberts http://da.vidr.cc/ On Thu, Nov 26, 2009 at 17:08, Anton Korobeynikov <anton at korobeynikov.info> wrote:> Hello, David > >> Additional patch attached, is this suitable? > Looks good, thanks. What's about arithmetics? > >>> The current big question is: how you're planning to deal with >>> arbitrary precision stuff which might come from LLVM IR. >> I should be able to implement that. Would arbitrary precision support >> be required for the initial commit of the backend? > I really don't think so. But you should aware, that you can easy > obtain, say, i33 from C bitfields-heavy code, or i256 due to LLVM > optimizers. > > -- > With best regards, Anton Korobeynikov > Faculty of Mathematics and Mechanics, Saint Petersburg State University >-------------- next part -------------- A non-text attachment was scrubbed... Name: llvm-jvm-test.patch.gz Type: application/x-gzip Size: 1003 bytes Desc: not available URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20091126/0978b976/attachment.bin>
On Nov 26, 2009, at 12:14 AM, David Roberts wrote:>>> Additional patch attached, is this suitable? >> Looks good, thanks. What's about arithmetics? > Revised patch attached.Hi David, I'm not very excited about this patch. We already have a C backend and MSIL backend. Neither of those support the full generality of LLVM IR (for example, exceptions, 'weird' integers, etc) and therefore aren't reliable. I don't know of anyone using the MSIL backend and it continues to bit rot. IMO, the MSIL backend should just be removed. Who is the expected client of this code? Will it be maintained going forward? Is it going to cover the full generality of LLVM IR constructs? How do you plan to handle unsafe IR? -Chris> > -- > David Roberts > http://da.vidr.cc/ > > > > On Thu, Nov 26, 2009 at 17:08, Anton Korobeynikov > <anton at korobeynikov.info> wrote: >> Hello, David >> >>> Additional patch attached, is this suitable? >> Looks good, thanks. What's about arithmetics? >> >>>> The current big question is: how you're planning to deal with >>>> arbitrary precision stuff which might come from LLVM IR. >>> I should be able to implement that. Would arbitrary precision support >>> be required for the initial commit of the backend? >> I really don't think so. But you should aware, that you can easy >> obtain, say, i33 from C bitfields-heavy code, or i256 due to LLVM >> optimizers. >> >> -- >> With best regards, Anton Korobeynikov >> Faculty of Mathematics and Mechanics, Saint Petersburg State University >> > <llvm-jvm-test.patch.gz>
> Who is the expected client of this code?There are several reasons why compiling to JVM bytecode can be desirable. For example, it can be executed on platforms that do not support native code execution for security or other reasons e.g. browser applets, mobile devices, some webhosts. From the Java perspective, it allows libraries written in languages such as C to be used in a cross-platform manner, without the need for reliance on a native library through JNI.> Will it be maintained going forward?I can't guarantee anything, but I'll do my best to keep it maintained.> Is it going to cover the full generality of LLVM IR constructs? > How do you plan to handle unsafe IR?Sorry, I'm still relatively new to LLVM, so I'm not sure what you're refering to. If this patch is not to be included in the LLVM source tree, then is it possible to distribute backends as standalone tools? -- David Roberts http://da.vidr.cc/ On Fri, Nov 27, 2009 at 07:47, Chris Lattner <clattner at apple.com> wrote:> > On Nov 26, 2009, at 12:14 AM, David Roberts wrote: > >>>> Additional patch attached, is this suitable? >>> Looks good, thanks. What's about arithmetics? >> Revised patch attached. > > Hi David, > > I'm not very excited about this patch. We already have a C backend and MSIL backend. Neither of those support the full generality of LLVM IR (for example, exceptions, 'weird' integers, etc) and therefore aren't reliable. I don't know of anyone using the MSIL backend and it continues to bit rot. IMO, the MSIL backend should just be removed. > > Who is the expected client of this code? Will it be maintained going forward? Is it going to cover the full generality of LLVM IR constructs? How do you plan to handle unsafe IR? > > -Chris > >> >> -- >> David Roberts >> http://da.vidr.cc/ >> >> >> >> On Thu, Nov 26, 2009 at 17:08, Anton Korobeynikov >> <anton at korobeynikov.info> wrote: >>> Hello, David >>> >>>> Additional patch attached, is this suitable? >>> Looks good, thanks. What's about arithmetics? >>> >>>>> The current big question is: how you're planning to deal with >>>>> arbitrary precision stuff which might come from LLVM IR. >>>> I should be able to implement that. Would arbitrary precision support >>>> be required for the initial commit of the backend? >>> I really don't think so. But you should aware, that you can easy >>> obtain, say, i33 from C bitfields-heavy code, or i256 due to LLVM >>> optimizers. >>> >>> -- >>> With best regards, Anton Korobeynikov >>> Faculty of Mathematics and Mechanics, Saint Petersburg State University >>> >> <llvm-jvm-test.patch.gz> > >