similar to: [LLVMdev] JVM Backend

Hello, David First of all, thanks for the backend submission. I let Chris comment about the procedure of adding it to the tree. :) I just did a quick look into the code. The comments are below > Indirect function calls don't work yet, and there's probably some > minor bugs in it, but it works well for the test cases that I've run > through it. Could you please provide some

> Could you please provide some sort of "feature" test? So, we might be > sure that the stuff won't be broken due to e.g. some API change, etc. > Now we have a powerful FileCheck facility, so, you might just have a > one .ll file and check for the JVM code emitted. Additional patch attached, is this suitable? >> In order to link and run the output, the LLJVM[1]

> 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

>> > 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

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

> So it will stack overflow on tail calls At 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 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

> 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). -- David Roberts http://da.vidr.cc/ On Sat, Nov 28, 2009

Hi fellow devs, I was looking for converting LLVM IR to JavaBytecode by using lljvm project of https://github.com/davidar/lljvm They don't seem to compile, once i run *make* in the root directory it give me the error : cd include && make all make[1]: Entering directory `/home/rtiwari1/llvm_new/lljvm/include' make[1]: Nothing to be done for `all'. make[1]: Leaving

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

That source file was removed from LLVM in r232397 on March 16, 2015. It looks like lljvm hasn't been updated in a long time. LLVM's C++ APIs are not stable, so there is no expectation that a project built against LLVM's C++ API in 2015 would build or reasonably function against LLVM trunk. The project probably works against LLVM 3.6.2 which was (I believe) the last LLVM release to

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

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

My idea was to create a complete backend treating Java as a normal platform, to enable LLVM to compile programs to Java Bytecode (.class) and Java Archive files (.jar). This could be useful in situations where we need to compile a program for a platform still not natively supported by LLVM. I don't know if it exists already, I've heard about this "LLJVM" but I don't think it

> 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

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'

>> 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?

> If you translate to a big array of memory and index into it, how is it > better than the mips -> java compiler? Yes, it is similar to the mips to java compiler in that regard, but it does have several advantages over it. For example, functions are mapped to individual methods (rather than just a big chunk of translated instructions), allowing Java to call individual functions in the

Hi All, So close and yet so far.? ;-( Have been migrating users from an old Dovecot server to a new one. All of the users have doveadm backup'd perfectly, except for one ! What does the below mean ? $ sudo doveadm -v -o imapc_user=jd at example.org.tld -o imapc_password=secretSquirrel -o imapc_host=old-server.example.com backup -1 -R -u jd at example.org.tld imapc: dsync(jd at

Hi fellow devs, I was looking for a way to run C on the JVM and i found LLJVM which apparently does exactly that! Howevere,unfortunately it seems dead on the main david's git https://github.com/davidar/lljvm as well as the slightly newer one https://github.com/hyc/lljvm. They don't seem to compile, once i run make in the root directory it give me the error : " *In file included

Hi, I am begineer to llvm, implementing a main.cpp from https://github.com/davidar/lljvm/blob/master/backend/main.cpp A) : When I am declaring a command: * PassManager PM* * PM.add(new DataLayout td)* It shows error: > *error: missing template arguments before ‘PM’* * PassManager PM;* ^ >*main_test.cpp:48:2: error: ‘PM’ was not declared in this scope* *