Re: [PATCH] Exploiting dual mode operation, implementation.

[Leehod Baruch <LEEHOD at il dot ibm dot com>]

> aside, I *still* do not believe that narrowing from hi->di to hi->si is
> useful.  They cost the same.

I know that they cost the same, this is exactly why the result is better.
Instead of two sign-extensions we have only one at the end.

> And, frankly, you'll find that essentially all of the optimization
> that can happen for free comes on the producer side, and not on
> the consumer side.  Thus I would expect the benefit to be had from
> catering to a "use2" that can automagically widen si->di to be minimal.

I agree that the common case is that we gain optimization for free
mostly on the producer side, but this doesn't cover all cases.
In many cases we don't need the sign-extension in the first place
since we are working on the lower part of the register only.
This is not automagically widen si->di.
Take compare on ppc for instance. It can be done on dual mode.
We can compare only the low part and throw the sign-extensions.

Beside, if what you say is true then what is the point of this
optimization?
Since the sign-extensions are currently generated after the def,
we could just combine them with the def (as it is done now during
regular combiner) and eliminate most of the sign-extensions.
But, this doesn't happen. The fact is that this optimizations
does throw many redundant sign-extensions.

My original point is that the algorithm as it was presented doesn't
cover cases like this.
Since the source of the sign extensions are of different modes
I can't just propagate them to before-the-use placement, and I can't
use redundancy elimination like lcm to throw them.
Maybe I'm missing something.
How would you expect the optimization as it was presented or with
modifications to deal with such cases?


Thanks,
Leehod.