On 01/27/15 13:36, Segher Boessenkool wrote:
On Tue, Jan 27, 2015 at 12:27:38PM -0700, Jeff Law wrote:
On 01/26/15 22:11, Segher Boessenkool wrote:
On Mon, Jan 26, 2015 at 08:07:29PM -0700, Jeff Law wrote:
The second change we need is an additional simplification.
If we have
(subreg:M1 (zero_extend:M2 (x))
Where M1 > M2 and both are scalar integer modes. It's advantageous to
strip the SUBREG and instead have a wider extension.
Should you also check M1 is not multiple registers?
We're generally working with pseudos, so we could estimate, but not know
for sure if we're dealing with multiple hard regs. But more
importantly, I'm not sure what that check would buy us.
I mean e.g. DI on a 32-bit target. My worry is that zero_extend:DI then
is more expensive -- if say, it is implemented as a split, combine itself
cannot get rid of the redundancy.
We might lose for a case like (subreg:DI ({zero,sign}_extend:SI (x))) on
a 32 bit target if something were able to recognize that the upper bits
were don't cares.
The most likely place for that to happen would be at assembly output
time -- but that would require the target to exploit the don't care
semantics of those bits. I don't recall any port doing that.
We could exploit this in generic splitting code, but I don't think we
do. lower-subreg slams in a zero when it finds a paradoxical subreg and
we've asked for the high word. I don't immediately see that does
anything special when the operand of the subreg is anything other than
another reg or mem.
combine exploits the "don't care" nature of those bits to eliminate
masking and such. It's not going to be able to eliminate the subreg
entirely unless it folks into some later insn and we're ultimately able
to narrow the operation back down to SImode.
Also note that while ports may not have special cases around the subreg
variant, several have special cases for ZERO_EXTEND. Basically they
slam in a zero to the upper word, either via a splitter or during
assembly code output. Those special cases will be recognized more often
now.
Jeff