This is the mail archive of the 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] copy propagation and the abstraction penalty

On Thursday, May 15, 2003, at 01:09 PM, Joe Buck wrote:

On Thu, May 15, 2003 at 10:10:22AM -0400, Diego Novillo wrote:

There's a few bits still missing, but we should be getting there.  In
this particular testcase I see:

      * Structures.  We only build enough SSA links to prove liveness.
        Two alternatives to dealing with this is using ESSA from the
        SSAPRE engine and/or rely on a scalarization pass.

Since this is the absolutely most common defect in our current C++
compiler, it seems worth trying to tune optimization to solve it directly,
rather than trying to solve a harder, more general problem.

If copy propagation can store the content of individual structure fields,
then it seems that you don't need the rest of scalarization

But the amount of memory necessary to do SSA on component_refs gets *really* large unless you share the component_refs for the SSA variables where possible.
Diego and I went through this back when we had Factored Use-Def chains.

I really think we *should* have structure accesses renamed, and it's easier than doing pointer renaming (since unions are the only thing you have to really worry about, and you can calculate the offsets).
It's just something that we had punted on until later (after the great FUD chain -> renaming switchover).
I guess now = later.

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