Re: Definition of basic blocks

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.


DoDi

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