Re: Basic blocks and compilers

Christian Christmann <plfriko@yahoo.de> wrote:


> I don't understand why the compiler
> 1) is not spliting basic block .L2 into two blocks where
> the second block just contains the instruction "j .L3".
> I though that each re-direction of the control flow imposes the
> creation of a new basic block (like .L4 and .L3). The instuction
> "jlt %d15, %d0, .L5" can possibly direct the program flow to .L5 and
> thus, in my opinion, the basic block should end here.
> 2) splits block .L5 and .L4? There are no
> calls to label .L4, so, according to my understanding, all instructions
> of blocks .L5 and .L4 should be held in one block.
>
> Might these two points be bugs or do the authors of the tricore-gcc
> have a different definition of basic blocks?


It would have been helpful to see the C code in comparison, but I can
guess what it looks like.


Short answer: there are no 'basic blocks' in assembly as such, only
Zuul^Wjump targets. If the compiler doesn't see a (possible) need to
jump to a certain location, why should it generate a label for that
location?


The .L2 'block' for example is the implementation of an if() itself,
including jump the 'then' part (jit ... .L5) and jump to the 'else' part
(j .L3), so having a label for the 'j .L3' doesn't make sense.


You are right that label .L4 is not targeted at all, and I can't explain
why - it might be just an artifact of GCC's code generation - but keep
in mind that with -O0 gcc does no optimization at all, as evidenced by
the 'j .L1' immediately followed by the .L1 label. Run gcc with -O1 or
above, and you should see improvements in the generated assembly.
--
Lars Duening; lars at bearnip dot com

Return to the comp.compilers page.
Search the comp.compilers archives again.