Re: paradoxical subreg problem

[Richard Earnshaw <rearnsha at arm dot com>]

> 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.

Yep, that summarizes my understanding as well.

Most of this rubbish seems to come about because register_operand accepts 
subreg(mem) as a valid register.  This has always seemed daft to me, and 
indeed the arm back-end hardly ever uses register_operand because of this 
(it seems to generate worse code by forcing spills during reload that 
would otherwise have been caught during general register allocation).

R.