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
