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

Reply via email to