[RFC] [P2] [PR tree-optimization/33562] Lowering more complex assignments.

[Jeff Law]

On 02/12/2016 02:04 AM, Richard Biener wrote:
>>
>> So what am I missing here?  Is there any kind of aliasing issues I need to
>> be aware of?  Any other dragons lurking?
>
> I think what you are missing is that you'll "optimize"
>
> _Complex double x, y;
>
> void foo (void)
> {
>    x = y;
> }
>
> then but dependent on the targets capability DCmode moves might be
> cheaper than four DFmode moves and nothing will combine them together
> again.
True.  In today's world where we can load/store large objects 
efficiently, that effect probably dwarfs anything we get from handling 
the trivial/artificial cases with more lowering.


>
> In complex lowering we're careful to only "optimize" when we know how to
> extract components in an efficient way (well, mostly).
Right.  If I understood the stuff in tree-complex, it's mostly concerned 
with lowering when the complex object is actually a degenerate.

>
> That the DSE opportunities in complex-[45].c are exposed if you lower
> the aggregate inits is obvious but the lowering is only a workaround for
> our lack of handling for this case.  I think the specific cases can be
> easily made work by enhancing tree DSE in dse_possible_dead_store_p
> to pick up partial kills by adjusting *ref (its offset/size) - keeping the
> original ref for picking up uses.
>
> But really we simply need a better DSE algorithm.
So the way to fix DSE is to keep the existing algorithm and track the 
hunks of Complex/aggregates that have been set a second time.

My first thought was to implement this as an inverted bitmap.  ie, set 
it to 1 for every byte in the complex/aggregate that is set by the first 
store.  Clear bits for each byte in subsequent stores to the pieces. 
If the bitmap reaches an empty state, then the initial store is dead.

Adjusting *ref could work too, but would probably be painful if the 
subsequent stores don't happen in a convenient order.


jeff