[Bug target/27405] gcc.c-torture/execute/960209-1.c ICEs on sh64-* with -O3

["amylaar at gcc dot gnu dot org" <gcc-bugzilla@gcc.gnu.org>]

------- Comment #1 from amylaar at gcc dot gnu dot org  2006-05-08 19:44 -------
(In reply to comment #0)
> It seems that this move insn is generated at loop-invariant.c:
> move_invariant_reg().

Yes.  In general, we say that we don't want such SUBREGS to appear in the
first place, since then they could be propagated by the optimizers into
contexts where they don't belong.
However, that has already happened in this case.  THe subreg originally
appeared in:

(insn 183 204 184 17 (set (subreg:DI (reg:SI 205) 0)
        (gt:DI (reg/v:SI 169 [ q ])
            (reg:SI 210))) 14 {cmpgtsi_media} (nil)
    (nil))

In this context, the SUBREG is fine, because equality / inequality comparison
operators can generate only 0 or 1.  And tere is also a good reason to have
these operator always generate the same mode: this is required in order for
cse to function properly.

I don't think recognizing the move in insn 206 is the right way forward; the
subreg be further propagated into contexts where it does not belong.

Another approach would be to say that the loop invariant motion code should
have uses an SImode register, since the destination of the original instruction
was also ultimately an SIMode register.  However, that would mean that we
couldn't share the invariant with other uses where an DImode comparison result
is wanted.

The problem is that we loose information when we say that the result of the
comparison is DImode: we don't know any more that the value is suitable
for SImode without sign-extension.
On the other hand, if an SImode value is held in a general purpose register,
we know that we can use this register to get the sign-extended DImode value.

Thus, I think the right solution is to change the SHmedia setCC insns to
generate SImode values.  That will mean that for DImode there will initially be
ianother temporary register, and an extra sign extension insn.  We'll have
to check that SI->DI sign extensions can be folded into all the uses that
matter - arith_reg_operand already allows them, so where
that predicate is used (directly or indirectly), we should be fine.


-- 

amylaar at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
     Ever Confirmed|0                           |1
   Last reconfirmed|0000-00-00 00:00:00         |2006-05-08 19:44:04
               date|                            |


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27405