Re: Basic blocks and compilers (Lars Duening)
9 Jan 2006 23:56:09 -0500

          From comp.compilers

Related articles
[2 earlier articles]
Re: Basic blocks and compilers ( (2006-01-09)
Re: Basic blocks and compilers (2006-01-09)
Re: Basic blocks and compilers (Hans-Peter Diettrich) (2006-01-09)
Re: Basic blocks and compilers (Paolo Bonzini) (2006-01-09)
Re: Basic blocks and compilers (Ken Rose) (2006-01-09)
Re: Basic blocks and compilers (Stephen Clarke) (2006-01-09)
Re: Basic blocks and compilers (2006-01-09)
| List of all articles for this month |

From: (Lars Duening)
Newsgroups: comp.compilers
Date: 9 Jan 2006 23:56:09 -0500
Organization: Compilers Central
References: 06-01-009
Keywords: analysis
Posted-Date: 09 Jan 2006 23:56:09 EST

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

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

Post a followup to this message

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