Re: [PATCH] Promoted variable SUBREG optimizations

[Roger Sayle <roger at eyesopen dot com>]

On Mon, 11 Aug 2003, Richard Henderson wrote:
> On Sat, Aug 09, 2003 at 09:33:25AM -0600, Roger Sayle wrote:
> > But most importantly, when generating the SUBREG it records the fact
> > that source register already contains the sign or zero extended
> > DImode representation of the value for the RTL optimizers to use.
>
> Well, the thing is, at best all it says is that at one point the
> value contained a sign extended representation of the value.  Even
> there I would only really trust the "at one time" part to apply to
> parameters, not local variables.

Hi Richard,

My reading of the documentation of SUBREG_PROMOTED_VAR_P both in rtl.h
and rtl.texi didn't reflect the "at one time" semantics you describe.
I'm not disagreeing, I find it quite plausible that this flag might not
always be updated correctly.  I take it that the documentation describes
the intended behaviour, but not what can be safely relied upon (yet)?


> For instance, by the time we get to combine, we could have generated
>
> (define_insn "*addsi_internal"
>   [(set (match_operand:SI 0 "register_operand" "=r,r,r,r")
>         (plus:SI (match_operand:SI 1 "reg_or_0_operand" "%rJ,rJ,rJ,rJ")
>                  (match_operand:SI 2 "add_operand" "rI,O,K,L")))]
>   ""
>   "@
>    addl %r1,%2,%0
>    subl %r1,%n2,%0
>    lda %0,%2(%r1)
>    ldah %0,%h2(%r1)")
>
> Note that the last two alternatives do *not* preserve sign extension
> to DImode.  And yet there's nothing stopping an extended subreg from
> being placed here.

I'm really sorry, but I have difficulty reading "machine descriptions".
Could you explain what goes wrong above?  The comments in rtl.h seem
to imply that an extended subreg can only be used as a LHS, when the
required extension gets performed.  [But that might not be relevant].


> I think extended subregs are a fringe feature that too many parts of
> the compiler don't know about, and so don't universally ensure that
> its constraints are really met.  I don't think you can *realiably*
> add code that depends on it.

You're probably right.  I take it that you're happy with the dojump.c
hunk of the patch, that is sufficient to fix the uninit-A.c failure
on alpha?  This occurs at RTL expansion time before any of the RTL
optimizers have had a chance to break anything.  I believe that we
can guarantee SUBREG_PROMOTED_VAR_P's invariants are preserved during
middle-end "expansion".

If so, let me know and I'll rerun a bootstraps and regression checks
with just that change.  If not, do you have any suggestions on how
to tackle gcc.dg/uninit-A.c?

Many thanks again,

Roger
--