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) |
|
This is a correction to my own earlier post. I accidentally missed a
"not" in the following:
> ... then the simplest
> solution would be to treat procedure calls as block boundaries. The
> blocks won't be basic blocks any more -- but they probably will be
> what you want.
I meant to suggest *not* treating procedure calls as block
boundaries.