Re: register allocation: basic blocks, liveness and next use

On Mar 23, 1:16 pm, Max Hailperin <m...@gustavus.edu> wrote:
> Gene <gene.ress...@gmail.com> writes:
> > On Mar 22, 8:22 pm, kphillips <kevin.phillip...@yahoo.com> wrote:
> >> ... Am I missing something here?
>
> > Perhaps the definition of a basic block.
>
> Actually, the original poster doesn't seem to have missed the
> definition of a basic block. The CALL instructions do create basic
> block boundaries. And what you say in the remainder of your message
> doesn't contradict this. Instead, you seem to be suggesting that he
> missed the definition of a temporary.
>
> > The definition of a temporary requires that none of its defs can reach
> > the end of the corresponding block. Obviously your t1..3 don't meet
> > this requirement.
>
> I'm not convinced that "temporary" has a consensus meaning, the way
> "basic block" does. I've seen plenty of authors other than the
> original poster use "temporary" to mean "a name introduced by the
> compiler, as opposed to appearing in the source code."
>
> But even if we accept your definition of "temporary" as meaning
> "local" (to a basic block), the way you would do that would not be by
> stipulating that the definitions can't reach the end of the block, but
> rather by stipulating that they not be live at the end of the block.
> The last of the definitions for any given name will always reach the
> end of the block. (Recall, a definition "reaches" a point if control
> must have passed through the definition on the way to the point
> without passing through any other definition of the same name in
> between.)


You're right I should have said temps must be dead at the end of the
block, not unreachable. Terminology brain cramp. Sorry


On the other hand, I disagree about basic blocks. I was refering to
the ASU definition -- maximal sequences of code with no gotos. The
intent is for block boundaries to fall at branches and convergences of
flow. Call/returns don't cause flow branches. In this case, the OP
is apparently using library calls for array indexing and output,
certainly non-branching operations.

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