Re: avoid try_split recursion on sequence

[Clinton Popetz <cpopetz at cygnus dot com>]

On Thu, Apr 13, 2000 at 03:21:37PM -0700, Richard Henderson wrote:
> On Thu, Apr 13, 2000 at 02:08:12PM -0500, Clinton Popetz wrote:
> > I found a case where an attempted split would result in a sequence, the first
> > insn of which was equal to the original insn, so emit-rtl would recurse
> > infinitely.
> 
> Hmm.  Is it perhaps instead a bug in the splitter?  One would
> hope that you wouldn't split anything that didn't need splitting,
> and that you would make progress if you did split.

Yes, but considering we handle one case of this sort, we should handle the
other.  Then we get an unrecognizable-insn ICE instead of a crash.

FWIW, the situation pops up when trying to get the ppc backend to work well
from a 64 bit host targeting 64 bit ppc.  There are various patterns like this:

(define_split
  [(set (match_operand:DI 0 "gpc_reg_operand" "")
	(ior:DI (match_operand:DI 1 "gpc_reg_operand" "")
		(match_operand:DI 2 "non_logical_u_cint_operand" "")))]
  "TARGET_POWERPC64"
  [(set (match_dup 0) (ior:DI (match_dup 1) (match_dup 3)))
   (set (match_dup 0) (ior:DI (match_dup 0) (match_dup 4)))]
"
{
      operands[3] = GEN_INT (INTVAL (operands[2])
			     & (~ (HOST_WIDE_INT) 0xffff));
      operands[4] = GEN_INT (INTVAL (operands[2]) & 0xffff);
}")

which feed back into themselves when the high 32 bits of a CONST_INT are
non-zero.  On aix64, with no gdb, and an executable that dbx doesn't really
like, I'd much rather see an ICE than a stack overflow when fixing these :)

				-Clint