WORD_REGISTER_OPERATIONS/LOAD_EXTEND_OP

WORD_REGISTER_OPERATIONS/LOAD_EXTEND_OP

[Bernd Schmidt]

Can someone tell me what assumptions are made by this piece of code in
combine.c (nonzero_bits):

#if defined (WORD_REGISTER_OPERATIONS) && defined (LOAD_EXTEND_OP)
          /* If this is a typical RISC machine, we only have to worry
             about the way loads are extended.  */
          if (LOAD_EXTEND_OP (GET_MODE (SUBREG_REG (x))) == SIGN_EXTEND
              ? (((nonzero
                   & (((unsigned HOST_WIDE_INT) 1
                       << (GET_MODE_BITSIZE (GET_MODE (SUBREG_REG (x))) - 1))))
                  != 0))
              : LOAD_EXTEND_OP (GET_MODE (SUBREG_REG (x))) != ZERO_EXTEND)
#endif

I've got a sparc testcase here (PR 1061) where a masking operation is missing
in the output.  It appears that this piece of code assumes that if W_R_O and
L_E_O are defined, an expression like (subreg:SI (reg:HI x)) always has all
bits zero in the upper half.  This isn't the case, though - this seems like
it's just an invalid optimization and should be removed.

Comments?


Bernd

Re: WORD_REGISTER_OPERATIONS/LOAD_EXTEND_OP

[Richard Earnshaw]

> Can someone tell me what assumptions are made by this piece of code in
> combine.c (nonzero_bits):

IIRC they are:

(REG:mode1 x) has just been loaded from memory.

mode1 < word size (mode2)

loads of size mode1 zero- or sign-extend automatically to mode2.  That is, 
in effect

(set (reg:mode1 x) (mem:mode1 ...))

is equivalent to

(set (reg:mode1 x) (subreg:mode1 (..._extend:mode2 (mem:mode1 ...)) 0))

for this machine.

> 
> #if defined (WORD_REGISTER_OPERATIONS) && defined (LOAD_EXTEND_OP)
>           /* If this is a typical RISC machine, we only have to worry
>              about the way loads are extended.  */
>           if (LOAD_EXTEND_OP (GET_MODE (SUBREG_REG (x))) == SIGN_EXTEND
>               ? (((nonzero
>                    & (((unsigned HOST_WIDE_INT) 1
>                        << (GET_MODE_BITSIZE (GET_MODE (SUBREG_REG (x))) - 1))))
>                   != 0))
>               : LOAD_EXTEND_OP (GET_MODE (SUBREG_REG (x))) != ZERO_EXTEND)
> #endif
> 
> I've got a sparc testcase here (PR 1061) where a masking operation is missing
> in the output.  It appears that this piece of code assumes that if W_R_O and
> L_E_O are defined, an expression like (subreg:SI (reg:HI x)) always has all
> bits zero in the upper half.  This isn't the case, though - this seems like
> it's just an invalid optimization and should be removed.
> 
> Comments?
> 
> 
> Bernd
> 

Re: WORD_REGISTER_OPERATIONS/LOAD_EXTEND_OP

[Bernd Schmidt]

On Sat, 7 Apr 2001, Richard Earnshaw wrote:

> > Can someone tell me what assumptions are made by this piece of code in
> > combine.c (nonzero_bits):
>
> IIRC they are:
>
> (REG:mode1 x) has just been loaded from memory.
>
> mode1 < word size (mode2)
>
> loads of size mode1 zero- or sign-extend automatically to mode2.  That is,
> in effect
>
> (set (reg:mode1 x) (mem:mode1 ...))
>
> is equivalent to
>
> (set (reg:mode1 x) (subreg:mode1 (..._extend:mode2 (mem:mode1 ...)) 0))
>
> for this machine.

That's essentially what LOAD_EXTEND_OP means.  The question is, what exactly
does WORD_REGISTER_OPERATIONS mean?  Apparently, the code assumes that a
(subreg:mode2 (reg:mode1)) always has the upper half properly extended.
That's not the case, however: consider left shifts and (unsigned) additions
and subtractions.  To me it seems like the entire concept behind
WORD_REGISTER_OPERATIONS is flawed.

If no one objects, I will rip out this macro some time next week.


Bernd

Re: WORD_REGISTER_OPERATIONS/LOAD_EXTEND_OP

[Joern Rennecke]

> That's essentially what LOAD_EXTEND_OP means.  The question is, what exactly
> does WORD_REGISTER_OPERATIONS mean?  Apparently, the code assumes that a

tm.texi explains this:

@findex WORD_REGISTER_OPERATIONS
@item WORD_REGISTER_OPERATIONS
Define this macro if operations between registers with integral mode
smaller than a word are always performed on the entire register.
Most RISC machines have this property and most CISC machines do not.

> (subreg:mode2 (reg:mode1)) always has the upper half properly extended.
> That's not the case, however: consider left shifts and (unsigned) additions
> and subtractions.  To me it seems like the entire concept behind
> WORD_REGISTER_OPERATIONS is flawed.

No, the way combine uses it is flawed.  Instead of widining the values just
before checking, it should widen the operations that are folded.

Re: WORD_REGISTER_OPERATIONS/LOAD_EXTEND_OP

[Bernd Schmidt]

On Wed, 11 Apr 2001, Joern Rennecke wrote:

> > That's essentially what LOAD_EXTEND_OP means.  The question is, what exactly
> > does WORD_REGISTER_OPERATIONS mean?  Apparently, the code assumes that a
>
> tm.texi explains this:
>
> @findex WORD_REGISTER_OPERATIONS
> @item WORD_REGISTER_OPERATIONS
> Define this macro if operations between registers with integral mode
> smaller than a word are always performed on the entire register.
> Most RISC machines have this property and most CISC machines do not.

I know, but why would an optimizer want to know this?

> > (subreg:mode2 (reg:mode1)) always has the upper half properly extended.
> > That's not the case, however: consider left shifts and (unsigned) additions
> > and subtractions.  To me it seems like the entire concept behind
> > WORD_REGISTER_OPERATIONS is flawed.
>
> No, the way combine uses it is flawed.  Instead of widining the values just
> before checking, it should widen the operations that are folded.

Hmm?  You mean if it sees a HImode operation it should widen it to SImode?
But if WORD_REGISTER_OPERATIONS is defined, we won't even see HImode
operations because the machine doesn't define patterns for them, right?

Still confused,


Bernd

Re: WORD_REGISTER_OPERATIONS/LOAD_EXTEND_OP

[Joern Rennecke]

> Hmm?  You mean if it sees a HImode operation it should widen it to SImode?
> But if WORD_REGISTER_OPERATIONS is defined, we won't even see HImode
> operations because the machine doesn't define patterns for them, right?

There is no rule that says that smaller-than-word operations are not to have
patterns on a WORD_REGISTER_OPERATIONS machine.  And in fact, there are a
number of such patterns in existing ports.