[tree-ssa] copy propagation and the abstraction penalty

[Daniel Berlin]

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.
--Dan