Question: can the code generator backend be reused easily

[dibyendumajumdar]

Hi,

I am interested in reusing the code generator backend (initially x86-64) from OMR. I was wondering how modular this is - i.e. what is the interface between the backend and the rest of the system? Presumbly the IL is the interface?

Is it designed such that I can extract the code from IL below ... or are there upward dependencies?

Thanks and Regards Dibyendu

[dibyendumajumdar]

To start with can I just build the compiler component? Would appreciate any help / instructions.

Thank you!

[dibyendumajumdar]

BTW I am using CMake.

I tried hacking the CMakeLists.txt in the compiler folder to make it run standalone ... but no luck. It generated make files eventually but running make does nothing.

[fjeremic]

I was wondering how modular this is - i.e. what is the interface between the backend and the rest of the system? Presumbly the IL is the interface?

Hi @dibyendumajumdar, the interface is indeed the IL. It is up to the consuming project to generate it however so there is no frontend in OMR per say. There are libraries shipped with OMR such as jitbuilder (see corresponding directory) which can help you build IL to represent very high level operations.

Is it designed such that I can extract the code from IL below ... or are there upward dependencies?

The compiler component does not have upward dependencies. It only relies AFAIK on the port library for processor detection (someone correct me on this one if I'm wrong). However the compiler component is truly a component and is meant to be consumed by another project which must ship with a frontend that is able to generate IL which the compiler component will consume. There are several examples of this on the front page.

To start with can I just build the compiler component?

Unfortunately no the compiler component needs a frontend which will generate the IL. The jitbuilder library can help with this as it makes it very easy to start consuming the compiler component into a working JIT compiler. There are excellent articles written by @mstoodle [1] [2] [3] which can walk you through step-by-step how this is done. Reading these articles may be a good starting point for you. Let us know if you have more questions! We're happy to help.

[1] https://developer.ibm.com/open/2016/07/19/jitbuilder-library-and-eclipse-omr-just-in-time-compilers-made-easy/ [2] https://developer.ibm.com/open/2017/03/08/build-more-complicated-methods-using-the-jitbuilder-library/ [3] https://developer.ibm.com/open/2017/04/14/building-jitbuilder-library-source-code/

[dibyendumajumdar]

Hi @fjeremic

Thank you for the response. Yes I am aware that a front end needs to generate IL - I have a C front end that I am planning to use. All I need is the ability to build the compiler backend on its own - upon further investigation and reading the docs, it seems that the CMake build for compiler is not yet complete?

I will try to build this on my own anyway.

I am aware of JIT Builder etc but really I want to harness the full power of the backend IL and don't mind working directly with it.

Regards Dibyendu

[fjeremic]

upon further investigation and reading the docs, it seems that the CMake build for compiler is not yet complete?

It should be. Other subprojects like Tril (https://github.com/eclipse/omr/tree/master/fvtest/tril) also use CMake and build on top of the compiler component. I think what may be confusing you is that the compiler component by itself is not a shared library you can plug and play. It is meant to be consumed and built as part of a shared library or executable.

So if you want to generate IL on your own you will have to make your own CMakeList.txt defining an executable or shared library consuming the compiler component. Tril is a very concise example of this. See the CMake definitions inside of that project. This is my understanding anyway.

[Leonardo2718]

Hi @dibyendumajumdar,

upon further investigation and reading the docs, it seems that the CMake build for compiler is not yet complete?

CMake support is perhaps "not yet complete" in that it is still being worked on and support is not consistent accross platforms. However, as @fjeremic points out, Tril is actively using CMake. wasmjit-omr also uses CMake.

To start with can I just build the compiler component?

For historical, technical reasons, building the compiler as a standalone component is (practically) not possible. The compiler technology requires that the user implement certain functionality in order to make it a "complete" component.

I want to harness the full power of the backend IL and don't mind working directly with it.

I would suggest using JitBuilder anyways but with the IlInjector interface to generate IL (https://github.com/eclipse/omr/blob/master/compiler/ilgen/IlInjector.hpp), instead of the "conventional" *Builder interface. IlInjector gives you direct access to the IL and you can use it while still taking advantage of the sane defaults JitBuilder provides.

This is actually exactly what Tril does (as it turns out :grin:) so you can use it as an example.

If you're concerned about the overhead of JitBuilder, I don't think it will be significant during initial development. Once you have a working prototype, we'd be happy to work with you to either replace JitBuilder with the core OMR compiler or find a way to make JitBuilder more suitable to your needs. I assume this is for Ravi?

[dibyendumajumdar]

Hi @Leonardo2718

I have been trying to get the compiler build on its own. I saw that one needs to supply some 'env' implementations. Nearly there apart from couple of errors outstanding (at least I think so).

I think the good separation of the compiler component is a great feature of OMR - this is quite a rare quality actually. I have looked at the JIT implementations of many projects - usually there isn't a clear separation (only exception is NanoJIT). (I did find one thing that worried me - the compiler depends on 'omr.h' - why??? I think this is a bad thing as omr.h can pull in lots of stuff. For now I have just removed this dependency).

Ideally I would like to include the fvtest (compiler), tril and JITBuilder ... but I don't want port, thread etc. The problem is that this is not the direction OMR is heading.

Initially I will use this as a backend for my C project (dmr_C). Using it in Ravi is the ultimate goal, but I have found that by its nature the code for a dynamic language is very inefficient - unless one can specialise the bytecodes. In Ravi I do this with type annotations but not really sure whether this is going to be accepted by the Lua community. I guess you would have found similar performance barriers in your Lua experiment.

Regards Dibyendu

[dibyendumajumdar]

BTW I am trying to build on Windows 10 with Visual Studio 2017 / CMake.

I hit the problem described in issue #2405 .

[dibyendumajumdar]

I have hit multiple issues compiling with Visual Studio 2017. I will report them separately.

For now I have created a cutdown version that compiles successfully on Linux. I was unable to include fvtest yet because of dependency on omrport.

Here is my work in progress repo: https://github.com/dibyendumajumdar/nj

Since I do all my C/C++ dev using Visual Studio I need to get this working on that platform for a start.

[dibyendumajumdar]

Quick update:

I am almost able to build compiler/jitbuilder on Windows using Visual Studio 2017. The only outstanding issue right now is issue #2594 . Any help on that will be very much welcome

[dibyendumajumdar]

Hi - thanks to the work done by @samolisov I have been able to fix a bunch of issues on Windows. The compiler tests are now built - although 11 tests still fail for me.

[fjeremic]

although 11 tests still fail for me.

Which tests are those? We should probably open up a new issue for this and take a peek to check whether these are compiler issues or test issues (could also be machine issue).

[dibyendumajumdar]

Hi @fjeremic

Which tests are those? We should probably open up a new issue for this and take a peek to check whether these are compiler issues or test issues (could also be machine issue).

@samolisov said he expected 5 tests to fail - so I need to check if the failures can be reduced further. I will report the status once I have investigated a bit more.

[dibyendumajumdar]

Hi @Leonardo2718

I would suggest using JitBuilder anyways but with the IlInjector interface to generate IL (https://github.com/eclipse/omr/blob/master/compiler/ilgen/IlInjector.hpp), instead of the "conventional" *Builder interface. IlInjector gives you direct access to the IL and you can use it while still taking advantage of the sane defaults JitBuilder provides.

This is actually exactly what Tril does (as it turns out 😁) so you can use it as an example.

Cool - I loved what you have done with tril. I will probably start with the JITBuilder APIs as you suggest - my interest was in reducing the code footprint as well as not being limited by a higher level api.

Am I right in thinking that JITBuilder api is not just the JITBuilder project - parts of it live in the compiler itself?

Regards Dibyendu

[mstoodle]

Hi @dibyendumajumdar JitBuilder is a library that includes the OMR compiler. There is a "public" JitBuilder API which is currently defined by the implementation classes and resides inside the OMR compiler. The reason it lives there is so that these classes can be extensible classes, which means that any language JIT that extends the OMR compiler can add their own language-specific extensions to the JitBuilder implementation (for example, in a Java JIT one might add functions to read and write a Java heap array including the requisite null and bounds checks).

The public API need not live in the OMR compiler, but it currently does. I'm working now to separate the two APIs (the public API that JitBuilder clients should use, and the "public" API that the JitBuilder implementation classes need) so that clients no longer need to have anything from the OMR compiler in their namespaces. You can take a gander at #2397 if you're interested in how that might shake out (feedback welcome!).

Thanks for your interest! I look forward to hearing more about your progress!

[mstoodle]

@dibyendumajumdar also note that there's nothing about the JitBuilder library that forces you to use the JitBuilder API. If you're willing to #include the compiler's files directly, you should be able to code up your own equivalent of compileMethodBuilder() to feed TRIL directly into the compiler. While there might be a few "extra" things in that library compared to what you'd get with your own implementation, it should basically work "out of the box"...

[dibyendumajumdar]

Hi @mstoodle

There is a "public" JitBuilder API which is currently defined by the implementation classes, which reside inside the OMR compiler.

I had assumed that the JitBuilder is an external interface - but then I couldn't find much code in he JitBuilder project which led me to think that it is part of the compiler project.

I have looked at #2397 briefly - do have some thoughts on that, but wanted to understand it a bit more first.

The reason I am interested in avoiding JitBuilder if possible, is to reduce the footprint (size) of the compiler - I am keen to get it as small as possible. A 1-2 MB size would be ideal but I don't think that this is achievable. Although I may be able to strip out stuff I don't need once I understand the codebase better.

For above reason I was pleased to discover that I am able to exclude most of OMR - including the port library and thread library (which I was not expecting) which already makes it easier as I can focus just on the bits I need to use.

I think the current design of the compiler being a separate reusable component is fantastic and one that (I think) should be celebrated and retained if possible. This is really a rare quality in software design - in the other code bases I have seen (maybe excluding LLVM I don't know) very often the JIT compiler directly accesses objects/functions that do not belong to it. I can see why that might be easier to implement - but it does make the JIT engine less reusable (an example is the B3 JIT in WebKit).

Thank you for the great work you guys are doing.

Regards Dibyendu

[Leonardo2718]

Hi @dibyendumajumdar

I did find one thing that worried me - the compiler depends on 'omr.h' - why??? I think this is a bad thing as omr.h can pull in lots of stuff.

I don't have a complete answer for this, unfortunately. I know part of the goal of leveraging the port library in the compiler is to eliminate duplicate functionality, but I haven't been keeping up with the latest work. Feel free to ask questions about this and share your thoughts in #2333 and #1642.

[...] I have found that by its nature the code for a dynamic language is very inefficient - unless one can specialise the bytecodes. In Ravi I do this with type annotations but not really sure whether this is going to be accepted by the Lua community. I guess you would have found similar performance barriers in your Lua experiment.

Yes, I did indeed hit this same challenges in Lua Vermelha. I'm hoping I'll be able to make some more progress once I can work on it again.

Cool - I loved what you have done with tril.

Thanks! I'm glad to hear you like it :smile: .

Anyways, it sounds like you're making some excellent progress, so congrats! And thanks for keeping us posted and for sharing your thoughts with us!

[dibyendumajumdar]

Hi @mstoodle,

Is compiler/ilgen the JitBuilder implementation?

Regards

[samolisov]

Which tests are those?

On my Windows 10 machine, the result of the compilertest depends on which compiler I use to build OMR.

Clang 6.0:

[ RUN      ] JITX86OpCodesTest.UnaryTest
..\fvtest\compilertest\tests\X86OpCodesTest.cpp(1678): error:       Expected: convert(byteDataArray[i], FLOAT_POS)
      Which is: -9
To be equal to: _b2f(byteDataArray[i])
      Which is: 247
..\fvtest\compilertest\tests\X86OpCodesTest.cpp(1679): error:       Expected: convert(byteDataArray[i], DOUBLE_POS)
      Which is: -9
To be equal to: _b2d(byteDataArray[i])
      Which is: 247
..\fvtest\compilertest\tests\X86OpCodesTest.cpp(1678): error:       Expected: convert(byteDataArray[i], FLOAT_POS)
      Which is: -128
To be equal to: _b2f(byteDataArray[i])
      Which is: 128
..\fvtest\compilertest\tests\X86OpCodesTest.cpp(1679): error:       Expected: convert(byteDataArray[i], DOUBLE_POS)
      Which is: -128
To be equal to: _b2d(byteDataArray[i])
      Which is: 128
..\fvtest\compilertest\tests\X86OpCodesTest.cpp(1750): error:       Expected: convert(shortDataArray[i], FLOAT_POS)
      Which is: -9
To be equal to: _s2f(shortDataArray[i])
      Which is: 65527
..\fvtest\compilertest\tests\X86OpCodesTest.cpp(1751): error:       Expected: convert(shortDataArray[i], DOUBLE_POS)
      Which is: -9
To be equal to: _s2d(shortDataArray[i])
      Which is: 65527
..\fvtest\compilertest\tests\X86OpCodesTest.cpp(1750): error:       Expected: convert(shortDataArray[i], FLOAT_POS)
      Which is: -32768
To be equal to: _s2f(shortDataArray[i])
      Which is: 32768
..\fvtest\compilertest\tests\X86OpCodesTest.cpp(1751): error:       Expected: convert(shortDataArray[i], DOUBLE_POS)
      Which is: -32768
To be equal to: _s2d(shortDataArray[i])
      Which is: 32768
...
[==========] 34 tests from 9 test cases ran. (10536 ms total)
[  PASSED  ] 33 tests.
[  FAILED  ] 1 test, listed below:
[  FAILED  ] JITX86OpCodesTest.UnaryTest

MSVC 19.13.26129 for x64:

...
..\fvtest\compilertest\tests\LimitFileTest.cpp(163): error: Value of: foundPlus
  Actual: false
Expected: true
..\fvtest\compilertest\tests\LimitFileTest.cpp(163): error: Value of: foundPlus
  Actual: false
Expected: true
[  FAILED  ] OptionSetTest.WithDefault (46 ms)
...
THE SAME ERROR for the JITX86OpCodesTest.UnaryTest as for Clang.
...
[==========] 34 tests from 9 test cases ran. (12136 ms total)
[  PASSED  ] 29 tests.
[  FAILED  ] 5 tests, listed below:
[  FAILED  ] LimitFileTest.UseLimitFileTest
[  FAILED  ] LimitFileTest.UseLimitFileRangeTest
[  FAILED  ] OptionSetTest.UseOptionSets
[  FAILED  ] OptionSetTest.WithDefault
[  FAILED  ] JITX86OpCodesTest.UnaryTest

[mstoodle]

Is compiler/ilgen the JitBuilder implementation?

@dibyendumajumdar Yes, that's where it resides, in IlBuilder, MethodBuilder, BytecodeBuilder, ThunkBuilder, TypeDictionary, VirtualMachine, and a few auxiliary classes like IlType and IlValue. Part of building the JitBuilder library (libjitbuilder.a) packages up the OMR compiler along with these classes and just their header files so that a client can independently invoke the compiler. In your case, if you build directly against the OMR compiler component (i.e. the source in `omr/compiler/`, you should be able to create whatever IL makes you happiest :) . Just make sure you get the include path set up properly :) .

Actually, one of the (but not the only) primary reasons for separating out the client API is so that it can be imported directly into a runtime without needing the compiler implementation itself. There's prototype work going on right now to record JitBuilder IL calls in a persistent form, and then to "replay" those calls inside a compiler to actually do the compilation.

That sets the stage to be able to have a single JIT compiler living out-of-process serving some number of runtimes which would only need the recording part of the equation.

[dibyendumajumdar]

Hi @mstoodle

@dibyendumajumdar Yes, that's where it resides, in IlBuilder, MethodBuilder, BytecodeBuilder, ThunkBuilder, TypeDictionary, VirtualMachine, and a few auxiliary classes like IlType and IlValue. Part of building the JitBuilder library (libjitbuilder.a) packages up the OMR compiler along with these classes and just their header files so that a client can independently invoke the compiler. In your case, if you build directly against the OMR compiler component (i.e. the source in omr/compiler/, you should be able to create whatever IL makes you happiest :) . Just make sure you get the include path set up properly :) .

Thank you for the info. I am keen to understand the backend compiler - I am looking forward to stepping through some the JitBuilder tests / compiler tests in the debugger.

Actually, one of the (but not the only) primary reasons for separating out the client API is so that it can be imported directly into a runtime without needing the compiler implementation itself. There's prototype work going on right now to record JitBuilder IL calls in a persistent form, and then to "replay" those calls inside a compiler to actually do the compilation.

I am still not 100% clear what you mean by the Client API - is that the whole JitBuilder interface? It would be nice to have a doc describing what the JitBuilder interface consists of. (I have watched the videos / presentations).

That sets the stage to be able to have a single JIT compiler living out-of-process serving some number of runtimes which would only need the recording part of the equation.

I see - so a server handling compilation tasks? But then the server could as well be using some other technology - or even a C compiler; also requiring a server running may not be acceptable in many cases.

Regards

[dibyendumajumdar]

@samolisov @fjeremic

The results I get on Windows 10 64-bit using Visual Studio 2017:

[----------] Global test environment tear-down
[==========] 34 tests from 9 test cases ran. (15995 ms total)
[  PASSED  ] 23 tests.
[  FAILED  ] 11 tests, listed below:
[  FAILED  ] LimitFileTest.CreateVLogTest
[  FAILED  ] LimitFileTest.CheckVLogTest
[  FAILED  ] LimitFileTest.UseLimitFileTest
[  FAILED  ] LimitFileTest.UseLimitFileRangeTest
[  FAILED  ] LimitFileTest.UseLimitFileBoundTest
[  FAILED  ] LogFileTest.CreateTFLogTest
[  FAILED  ] LogFileTest.EmptyTFLogTest
[  FAILED  ] LogFileTest.KeywordsLogTest
[  FAILED  ] OptionSetTest.UseOptionSets
[  FAILED  ] OptionSetTest.WithDefault
[  FAILED  ] JITX86OpCodesTest.UnaryTest

11 FAILED TESTS
  YOU HAVE 6 DISABLED TESTS

I have a slightly later snapshot of OMR code base I think (sadly I copied the code rather than forking it as I wanted to remove a lot of stuff so I can't tell the exact version - but it was taken late last week). I don't yet see why I am getting more failures.

Update: the copy was as of 25th.

[mstoodle]

Hi @dibyendumajumdar,

I am still not 100% clear what you mean by the Client API - is that the whole JitBuilder interface? It would be nice to have a doc describing what the JitBuilder interface consists of. (I have watched the videos / presentations).

Well, that's part of the reason I'm trying to separate it out :) . For example, the public API for the IlBuilder class is currently what's in IlBuilder.hpp (see compiler/ilgen/IlBuilder.hpp). Everything in that class that's public is currently "callable" from a JitBuilder client. But only some of that public API is actually meant to be used by JitBuilder clients. The public instance functions that are capitalized are the public API while, for the most part, the public instance functions that begin with lower case are really part of the implementation of JitBuilder. Because it's the same class (IlBuilder) the two parts are mixed together. Once the client API lands, it will be much more clear what the JitBuilder API is because it will have no parts of the implementation in it. That will make it much easier to port the API to different languages as well.

I see - so a server handling compilation tasks? But then the server could as well be using some other technology - or even a C compiler; also requiring a server running may not be acceptable in many cases.

It could be a server. It could be a daemon running on the same machine. It could be a C compiler, but only if something generated C code to feed to it (which is possible, but probably slow and error prone :) ). While I don't expect this mode to be the only way people would use JitBuilder, I think it opens some very interesting doors.

[dibyendumajumdar]

Hi @mstoodle

Well, that's part of the reason I'm trying to separate it out :) . For example, the public API for the IlBuilder class is currently what's in IlBuilder.hpp (see compiler/ilgen/IlBuilder.hpp). Everything in that class that's public is currently "callable" from a JitBuilder client. But only some of that public API is actually meant to be used by JitBuilder clients. The public instance functions that are capitalized are the public API while, for the most part, the public instance functions that begin with lower case are really part of the implementation of JitBuilder. Because it's the same class (IlBuilder) the two parts are mixed together. Once the client API lands, it will be much more clear what the JitBuilder API is because it will have no parts of the implementation in it. That will make it much easier to port the API to different languages as well.

Okay that makes sense.

It could be a server. It could be a daemon running on the same machine. It could be a C compiler, but only if something generated C code to feed to it (which is possible, but probably slow and error prone :) ). While I don't expect this mode to be the only way people would use JitBuilder, I think it opens some very interesting doors.

gcc libjit has a feature where you can set a flag and it will record the JIT calls - and output them in a C file that can be compiled back! This allows a user to submit a bug report back by sending a recording of the calls.

I would suggest that these features be added as optional add-ons and not cause the compiler size to increase!

Regards

[mstoodle]

gcc libjit has a feature where you can set a flag and it will record the JIT calls - and output them in a C file that can be compiled back! This allows a user to submit a bug report back by sending a recording of the calls.

Ah, yes, that's the "record" and then "replay" function I obliquely referred to earlier. The idea was to produce something denser and more readily introspected than a C source file :) . If you go back far enough in the git history, you'll find a similar kind of mechanism implemented in the JitBuilder implementation files (it was just never formalized or completed and has now been removed in preparation for the "real" thing).

You seem very concerned about compiler code footprint, but you have never mentioned the dynamic memory footprint of the compiler, i.e. the amount of memory allocated by the compiler to do a compilation, which can be many times larger than the footprint of the compiler itself. Is it really executable size you're worried about, or are you also worried about runtime footprint? Can you tell us more about the scenario you're focusing on that is imposing these kinds of concerns?

[dibyendumajumdar]

Hi @mstoodle

You seem very concerned about compiler code footprint, but you have never mentioned the dynamic memory footprint of the compiler, i.e. the amount of memory allocated by the compiler to do a compilation, which can be many times larger than the footprint of the compiler itself. Is it really executable size you're worried about, or are you also worried about runtime footprint? Can you tell us more about the scenario you're focusing on that is imposing these kinds of concerns?

Actually worried about both. I originally wanted to use LuaJIT as a scripting language in a product I was developing - but because LuaJIT had some weird restrictions - and because its code base is so dense and difficult to understand - it was impossible for me to support it. So I decided to create Ravi - which is Lua backed by LLVM JIT. But of course - having a mammoth JIT engine that is also very slow to compile code makes it virtually useless - although LLVM can generate fantastic code.

Although the product I was planning to build never shipped (you can see some remains of it at https://github.com/redukti/OpenRedukti - including the scripting interface) - the dream is still there. Having created Ravi, I would like it to be used by the Lua community (and maybe game developers) - but it simply won't work with an LLVM backend. For a credible alternative to LuaJIT I need a small and fast JIT engine.

So then I tried NanoJIT but I found that while this is a small and fast JIT compiler - its register allocation is poor, so that the resulting code is pretty sub-optimal if you have branching in the code (it does local register allocation with some support for looping constructs).

I was resigned to starting something on my own - from scratch, but then decided to use OMR as a starting point. The reasons for using OMR are:

a) I like code that is well designed and has comments! b) I can trust that the code is well tested - not only because of the tests but also because of its pedigree c) It seems that the compiler part is reusable and much more tractable than LLVM in terms of size and complexity. I can hope to understand it and maybe amend it. d) On the negative side I don't get to write my own thing!

Of course the other factors - speed of compilation, memory usage, decent code generation - all of these remain to be proven - and may well be a show stopper.

BTW I have looked at several other JITs:

• gcc libjit - is not a JIT really as it uses intermediate files
• GNU libjit (lacks global register allocator and is not sufficiently tested / lacks test cases)
• B3 JIT in WebKit - supposedly reusable but not!
• And others not worth mentioning

Regards

[mstoodle]

Thanks for writing that up, @dibyendumajumdar . Very helpful (and we appreciate the kind words)!

I think I can safely say that everyone at OMR is very interested in how your project move forward, so I hope you'll keep us in the loop with your progress! And, of course, we'll do what we can to help with any issues you encounter.

As for writing your own thing: well, we welcome contributions here, so there's always a chance you'll find a way to scratch this particular itch as well :) .

[dibyendumajumdar]

Yes sure I will keep the group informed. I don't know if I should raise an issue here for any questions I have or send an email to the eclipse omr mailing list - please advise.

I am trying to understand the IL - trees, nodes, symbols and basic blocks. I read the docs but are there any simple examples of how to get started? Usually there is a lot of scaffolding in the tests / and also in JitBuilder so I cannot see how to use the core IL interface.

As an FYI, the C front-end I am using initially generates IR which is at the level of virtual registers - all structural constructs are resolved and not visible at this level; these are translated to appropriate alloca, load/store ops.

[Leonardo2718]

Yes sure I will keep the group informed. I don't know if I should raise an issue here for any questions I have or send an email to the eclipse omr mailing list - please advise.

Personally, I would love to see more activity on the mailing list :grin: . I would also like to see some progress made on #2447 . Can't promise I'll be able/qualified to help though.

I am trying to understand the IL - trees, nodes, symbols and basic blocks. I read the docs but are there any simple examples of how to get started? Usually there is a lot of scaffolding in the tests / and also in JitBuilder so I cannot see how to use the core IL interface.

The simplest IL generator I know of that manipulates Trees directly is Tril. But, as I've already mentioned, it "cheats" by using JitBuilder to handle a lot of the extra scaffolding required. To get a better idea of how it works, it might be helpful to run one of the Tril examples with logging enabled (run with the environment variable TR_Options=traceIlGen,traceFull,log=trtrace.log) and taking a look at the generated log.

There's also a prototype JIT compiler for Ruby that uses the core OMR compiler technology directly: https://github.com/rubyomr-preview/ruby/tree/ruby_2_4_omr/rbjitglue. It's a bit out of date and is no longer being developed but you should still be able to learn something from it.

Finally, the most developed user of OMR is, of course, Eclipse OpenJ9. The codebase is rather complex, however, and doesn't really qualify as a "simple example of how to get started."

IMHO, this is, unfortunately, one of our weakest points as a project (at least for the compiler component). We generally lack specifications, documentation, and examples for the IL. The extra scaffolding that's required to leverage the compiler technology obscures matters even further. However, as with so many other things, there is work underway to improve this. In particular, #2569 covers the effort to create a specification for the IL and its related APIs. Once we have something to show, it would be great to get any input or feedback you might have!

To help you move forward, is there anything specific about the IL you're looking to understand (e.g. how TreeTops work, how the TR::Node interface works, etc.)? Or, are you looking for information about how the IL works conceptually? Do you want examples demonstrating how to do something specific you need? Or, do you want general examples to get an idea of how you can structure/design your project? (I ask for selfish reasons :grin:, partially. Having concrete goals would help us progress faster.)

[dibyendumajumdar]

Hi @Leonardo2718

Thank you for the reply. I am looking at tril, compilertests and JitBuilder. Right now my ambition is to compile something like:

int func() { return 42; }

I think this is probably the hardest step; should get easier (I hope) after that.

Yesterday I was looking at OpenJ9 - and was surprised to see that it doesn't have ConcreteFE.hpp ! So made me realize that maybe what's required is fluid - a front-end can override a lot.

I am happy to document stuff as I understand more - so maybe I can help fill some of gaps in documentation.

[dibyendumajumdar]

I think an active mailing list is a good thing too. I will definitely keep posting my questions there.

[dibyendumajumdar]

Hi @Leonardo2718

I am still working on getting a minimal front-end compiling / building - so haven't got to IL generation yet.

The first component that I think we need to document is ResolvedMethod / Method classes - and what the requirement/expectation is.

[dibyendumajumdar]

Hi @Leonardo2718 @mstoodle

I have made some progress trying to use the lower level IL gen api. I have been looking at the Tril project as well as ILBuilder to figure out how to do things.

The wip api / tests are in my project at:

https://github.com/dibyendumajumdar/nj/tree/master/c-api

If this turns out to be of interest to OMR please let me know - I can try to contribute this back. Right now though I am building and discovering at the same time, so it is very incomplete and draft.

I have posted some questions on the mailing list.

Thanks for your help so far.

Regards Dibyendu

[dibyendumajumdar]

Hi - I just thought I will post an update here prior to closing this issue.

I now have:

• a JIT backend for a C compiler
• A JIT backend for Lua derivative language called Ravi

In summary to answer the question raised by this issue - it is indeed possible to use the OMR JIT backend without the larger OMR set. Most people writing JIT engines by hand would be better off using JitBuilder although I think this is not yet packaged nicely in a release. Hopefully when the C api for JitBuilder gets done this will become much easier. For my case since I was planning to use C as the intermediary, I am using the IL layer more directly, but borrowing code from JitBuilder when necessary.

I have also started to write up whatever I have learnt so far. Hopefully I will be able to complete the write up soon.

I will close this issue in 5 days.

Thank you everyone for helping me / answering my questions.