This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH] Promoted variable SUBREG optimizations
- From: Roger Sayle <roger at eyesopen dot com>
- To: Richard Kenner <kenner at vlsi1 dot ultra dot nyu dot edu>
- Cc: gcc-patches at gcc dot gnu dot org
- Date: Tue, 12 Aug 2003 13:08:07 -0600 (MDT)
- Subject: Re: [PATCH] Promoted variable SUBREG optimizations
On Tue, 12 Aug 2003, Richard Kenner wrote:
> I believe that the only references to the DImode parent register in
> the initial RTL are always are via this (SUBREG:SI/s (REG:DI parent))
> which has the SUBREG_PROMOTED_VAR_P bit set.
>
> No, because you might be sign- (or zero-, as appropriate) extending the
> variable and the simplification routines, even for the initial RTL,
> will notice and substitute the underlying register.
It's exactly my attempts to add these simplifications to the compiler
that have sparked this discussion. I believe that mainline currently
only refers to the parent via the SUBREG. Pretty much all of the
compiler ignores the SUBREG_PROMOTED_VAR_P flag, and so treats references
to them as if they would a normal subregs, and not clobber the rest of
the inner pseudo.
> Of course that's just my understanding of the intended behaviour from
> reading the comments. How well recog, reload and the rest of the
> compiler honor these semantics, you'd know far better than I. But
> clearly the alpha backend is relying upon them.
>
> Where?
The fact that we're using SUBREG_PROMOTED_VAR_P on the alpha must mean
that they're useful. Otherwise why have the flags? Perhaps, you mean
that the current code doesn't actually require the holding register is
always correctly sign or zero extended? This might be true. In which
case, perhaps we should just get rid of the SUBREG_PROMOTED_* flags
and just treat it as a conventional subreg with no requirements on the
high bits.
> I was the one who added this feature to the compiler and it was orginally
> motivated by Alpha.
Do you agree with RTH that the current implementation can't be relied
upon to preserve the required semantics?
Roger
--