This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [tree-ssa] Maintaining/representing def-use/use-def information



On Dec 15, 2003, at 6:28 PM, Chris Lattner wrote:


On Mon, 15 Dec 2003, Daniel Berlin wrote:
On Dec 15, 2003, at 5:07 PM, Chris Lattner wrote:
Yes, you could do E-Path PRE, but it's harder to extend it to perform
strength reduction or load speculation.

Yup, and FWIW, LLVM uses an e-path based formulation of PRE on SSA form.
I remember looking at it.
Did I mention we can do LFTR too :P.

Something I've never understood about the SSAPRE paper and subsequent
extensions: why does it make sense to incorporate things like LFTR into
PRE? I understand the idea of integrating load/store motion into it, but
LFTR? It seems like a simplish problem. What am I missing?


It was easy?

Strength reduction i know they do because it does *straight line code* strength reduction, not just traditional loop based strength reduction.

IE it'll transform

a = b * 5
if (whatever)
{
	b = b + 1
}
a =  b * 5

into

pretmp = b * 5
a = pretmp
if (whatever)
{
pretmp = pretmp + <i'm working on a final and i don't feel like calculating the increment in my head :P>
b = b + 1
}
a = pretmp



The ability to repair "injuries" exposes quite a few more redundancies.



Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]