paradoxical subreg problem

[Jim Wilson]

In article <16350.1012242676@porcupine.cygnus.com> you write:
>Think very very carefully about the semantics of a paradoxical subreg.

A paradoxical subreg can have one of two different meanings, depending on
context.

1) The extra bits are don't care bits.  This usage can occur anywhere, and
   is primarily used when manipulating values larger than the word size.
   This perhaps requires that the operand be a register, but I'm not sure.
   For instance, on a 32-bit target, given (subreg:DI (reg:SI 100)), the
   extra 32-bits are don't care bits.
2) The extra bits are known to be zero or one, depending on whether loads
   zero or sign extend by default.  This is only used for values smaller than
   or equal to the the word size, and I think this also requires that the
   operand be a MEM, but I'm not positive about the last condition.  For
   instance, on a 32-bit target with zero-extending loads, given
   (subreg:SI (mem:QI ...)), the extra 24-bits are known to be zero.  This
   usage occurs only between combine and reload.

It has been this way for over a decade I'd say.

The first meaning came first, and has obvious uses.  I believe the second
meaning arose because of our primarily CISC oriented view at the time.
Since predicates know about subregs already, using subregs for zero/sign
extended loads means that they would be accepted automatically.  If we
added the explicit zero/sign extension operators, then a lot of predicates
and patterns would have to be modified to allow zero/sign extension operators.
Nowadays, the prevailing wisdom is that you should never create an insn
that will require a reload, and thus it may be that the second type of
paradoxical subreg is no longer useful.  We already have the problem that
combine.c and recog.c have special code checking INSN_SCHEDULING to get rid
of the second class of paradoxical subregs.  This code is unclean though,
as we never should have created these paradoxical subregs on a load/store
(RISC) machine to begin with.  If the patterns in the md file don't allow
MEM, then recog should not be accepting (subreg (mem)) as a register operand.

There might be a second justification that this feature allows for better
optimization, by exposing zero/sign extensions that would otherwise be
hidden.  However, I don't think this is convincing.  Combine has code to
keep track of sign-bit copies now, and we can do this just as well by using
explicit zero_extend/sign_extend operators instead of using subregs.

Jim