This is the mail archive of the
mailing list for the GCC project.
Re: [tree-ssa] copy propagation and the abstraction penalty
- From: Daniel Berlin <dberlin at dberlin dot org>
- To: Joe Buck <jbuck at synopsys dot com>
- Cc: Diego Novillo <dnovillo at redhat dot com>,"gcc at gcc dot gnu dot org" <gcc at gcc dot gnu dot org>
- Date: Thu, 15 May 2003 14:01:48 -0400
- Subject: 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
rather than trying to solve a harder, more general problem.
If copy propagation can store the content of individual structure
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.