Re: [omr-dev] Starting work on C front-end to OMR JIT

[Dibyendu Majumdar <mobile@xxxxxxxxxxxxxxx>]

Hi Leonardo,

On 17 June 2018 at 18:25, Leonardo <leonardo2718@xxxxxxxxxxxxxx> wrote:
>> > 3.  I am unclear how to generate conditional branches. First I tried:
>> >
>> > -   IfCmp cond goto BlockX
>> > -   Goto BlockY
>> >
>> > The compiler complained about the CFG.
>>
>> Looks like after the IfComp node the compiler expects to fall through
>> to next Block and expects a CFG edge to this block. Now in my case the
>> next block is not necessarily the false block - so the way I am trying
>> to work around is by introducing a proxy false block that simply does
>> GoTo to the real false block.
>
> That's correct. For conditional jumps, the branch is either taken or control falls through
> to the next block. I think using the next block to specify an alternative target is the
> correct way to handle your case.

Okay thank you.
My next challenge is going to be C switch/case construct. Does the IL
support this use case? I am guessing it does but haven't yet looked at
this. Any tips with regards to blocks / CFGs in this regard would be
appreciated.

>
> In case you haven't seen this yet, the CFG is dumped immediately after the Trees in
> a trace log between <cfg></cfg> tags. This section of the log is often useful when
> debugging incorrect CFG errors.

Yes I saw that - was helpful in understanding the issue.

>
> Also, when the generated code doesn't behave the way you expect, in addition to
> looking at the generated assembly, it's often useful to look at the post-optimization IL.
> Search for "Post Optimization Trees" in a trace log (searching for "Post Opt" should
> work too). Comparing post-optimization IL with what comes out of IL generation can
> also be helpful. In case it wasn't obvious, the "n##n" preceding each node in a trace
> log tells you the unique ID of each node. This is helpful for figuring out how the
> compiler is manipulating the IL.
>
> Hopefully, these tips will be helpful for future debugging :)

Yes thank you very much for the detailed replies. Much appreciated.

>
>> The updated trace output his here:
>>
>> https://github.com/dibyendumajumdar/dmr_c/blob/master/tests/omr/strlen_fixed.log
>>
>> The generated strlen() function worked!
>
> That's awesome! I'm looking forward to your next milestone.
>

The great thing with having a C front end is that once it starts
working, a lot of code can be JITed . I have backend for Ravi that
generates C code ... so I can JIT that too.

So far following work in addition to strlen.

https://github.com/dibyendumajumdar/dmr_c/blob/master/tests/nano/store.c
https://github.com/dibyendumajumdar/dmr_c/blob/master/tests/nano/sumq.c
https://github.com/dibyendumajumdar/dmr_c/blob/master/tests/nano/testif.c

Regards
Dibyendu