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

Gene <gene.ressler@gmail.com>
Sun, 23 Mar 2008 19:27:05 -0700 (PDT)

          From comp.compilers

Related articles
register allocation: basic blocks, liveness and next use kevin.phillips83@yahoo.com (kphillips) (2008-03-22)
Re: register allocation: basic blocks, liveness and next use gene.ressler@gmail.com (Gene) (2008-03-22)
Re: register allocation: basic blocks, liveness and next use max@gustavus.edu (Max Hailperin) (2008-03-23)
Re: register allocation: basic blocks, liveness and next use max@gustavus.edu (Max Hailperin) (2008-03-23)
Re: register allocation: basic blocks, liveness and next use max@gustavus.edu (Max Hailperin) (2008-03-23)
Re: register allocation: basic blocks, liveness and next use kevin.phillips83@yahoo.com (kphillips) (2008-03-23)
Re: register allocation: basic blocks, liveness and next use gene.ressler@gmail.com (Gene) (2008-03-23)
Re: register allocation: basic blocks, liveness and next use cfc@shell01.TheWorld.com (Chris F Clark) (2008-03-23)
Re: register allocation: basic blocks, liveness and next use kevin.phillips83@yahoo.com (kphillips) (2008-03-27)
Re: register allocation: basic blocks, liveness and next use jeffrey.kenton@comcast.net (Jeff Kenton) (2008-04-03)
| List of all articles for this month |
From: Gene <gene.ressler@gmail.com>
Newsgroups: comp.compilers
Date: Sun, 23 Mar 2008 19:27:05 -0700 (PDT)
Organization: Compilers Central
References: 08-03-084 08-03-086 08-03-090
Keywords: registers, code
Posted-Date: 24 Mar 2008 10:25:49 EDT

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.



Post a followup to this message

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