|Definition of basic blocks firstname.lastname@example.org (Christian Christmann) (2005-11-08)|
|Re: Definition of basic blocks email@example.com (SM Ryan) (2005-11-12)|
|Re: Definition of basic blocks firstname.lastname@example.org (Thomas Schilling) (2005-11-12)|
|Re: Definition of basic blocks email@example.com (A Pietu Pohjalainen) (2005-11-12)|
|Re: Definition of basic blocks firstname.lastname@example.org (Ray Dillinger) (2005-11-27)|
|Re: Definition of basic blocks DrDiettrich@compuserve.de (Hans-Peter Diettrich) (2005-11-29)|
|From:||Thomas Schilling <email@example.com>|
|Date:||12 Nov 2005 16:38:32 -0500|
|Posted-Date:||12 Nov 2005 16:38:32 EST|
Christian Christmann wrote:
> Are both version correct?
I'd say so - some reasons:
If you want to define as "a sequence of instructions whose order is
independent of the data" then you need not split at call places, because
you can easily "emulate" this by letting defs(call-instr) =
caller-save-regs. This would mean fewer blocks and thus potentially
OTOH, if you want more sophisticated analyses, e.g. inter-procedure
register allocation, you probably do better making it an extra block,
especially in presence of indirect (i.e. data-dependent) calls.
Just some random thoughts ... Haven't done the latter, so far.
Return to the
Search the comp.compilers archives again.