[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [omr-dev] Starting work on C front-end to OMR JIT
|
Hi Dibyendu,
> > 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.
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.
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 :)
> 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.
--
Leonardo
Sent from ProtonMail, Swiss-based encrypted email.
