Re: Definition of basic blocks

Hans-Peter Diettrich <>
29 Nov 2005 16:07:30 -0500

          From comp.compilers

Related articles
Definition of basic blocks (Christian Christmann) (2005-11-08)
Re: Definition of basic blocks (SM Ryan) (2005-11-12)
Re: Definition of basic blocks (Thomas Schilling) (2005-11-12)
Re: Definition of basic blocks (A Pietu Pohjalainen) (2005-11-12)
Re: Definition of basic blocks (Ray Dillinger) (2005-11-27)
Re: Definition of basic blocks (Hans-Peter Diettrich) (2005-11-29)
| List of all articles for this month |

From: Hans-Peter Diettrich <>
Newsgroups: comp.compilers
Date: 29 Nov 2005 16:07:30 -0500
Organization: Compilers Central
References: 05-11-053 05-11-125
Keywords: analysis
Posted-Date: 29 Nov 2005 16:07:30 EST

Thanks for your detailed contribution :-)

Ray Dillinger wrote:

> > What I actually want to know, is, if call instructions are treated like
> > any other instruction or if they cause the end of a basic block.
> > I've encountered both versions. Some people use call instructions amid
> > a basic block, other use them at the end of a basic block and continue
> > with the subsequent instructions in a new block.
> > Are both version correct?
> Depends on the language and semantics. If your language is strictly
> call-by-value and there's no "funny stuff" going on (such as
> continuations or implicit side effects) then you can take a call as
> part of a basic block.
> If it's call-by-reference, things are a little murkier; I defer to
> someone with superior knowledge.
> As our moderator pointed out, if there are implicit side effects -
> variables in scope that aren't passed explicitly to the function, but
> the function can modify them - you need to break the block there.

As long as a BB reflects (strictly sequential) control flow, only
modifications of the point of (no) return can break this flow after an
call. Calling conventions (for themselves) cannot influence the return
address, also side effects become effective only in known places
(conditional or indirect jumps). When exceptions or longjmp's can occur,
then there exist more instructions besides calls and jumps, which can
break the control flow.

When data flow is of interest, things can become much more complicated,
because any analysis should know about all the possible modifications.
IMO it's quite useless to know, in which places weird things can happen,
without a formal description of these effects.


Post a followup to this message

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