RFA: (dataflow?) testsuite regression since last week

[Bob Wilson <bwilson at tensilica dot com>]

I'm still seeing two testsuite regressions for Xtensa compared to last
Friday:

gcc.c-torture/execute/920501-6.c
gcc.c-torture/execute/930921-1.c

Both tests fail at -O3 with "internal compiler error: in get_biv_step,
at loop-iv.c:792".  Neither the Xtensa port nor the loop-iv.c code has
changed since last week in a way that obviously affects this. I'm
suspecting it is somehow related to the dataflow merge, but I don't see any 
obvious connections there, either.

I'm not very familiar with loop-iv.c so I would appreciate help
figuring out how to fix this.

Here is what appears to be happening for 930921-1.c.  The test program is:

f (x)
     unsigned x;
{
  return (unsigned) (((unsigned long long) x * 0xAAAAAAAB) >> 32) >> 1;
}

main ()
{
  unsigned i;

  for (i = 0; i < 10000; i++)
    if (f (i) != i / 3)
      abort ();
  exit (0);
}

At -O3, function f is inlined into main and "x * 0xAAAAAAAB" is recognized as
a DImode induction variable.  I'm pretty sure the problem is related
to the lack of an adddi3 pattern in xtensa.md.  We rely on optabs.c to
expand DImode addition.  If I dump the RTL file, the induction
variable increment looks like:

;; ivtmp$55 = ivtmp$55 + 0x0aaaaaaab
(insn 26 25 27 930921-1.c:4 (set (reg:DI 50)
        (mem/u/c/i:DI (symbol_ref/u:SI ("*.LC1") [flags 0x2]) [2 S8 A64])) -1 
(expr_list:REG_EQUAL (const_double -1431655765 [0xaaaaaaab] 0 [0x0] 0 [0x0] 0 
[0x0] 0 [0x0] 0 [0x0])
        (nil)))

(insn 27 26 28 930921-1.c:4 (clobber (reg:DI 51)) -1 (nil))

(insn 28 27 29 930921-1.c:4 (set (subreg:SI (reg:DI 51) 4)
        (plus:SI (subreg:SI (reg:DI 45 [ ivtmp$55 ]) 4)
            (subreg:SI (reg:DI 50) 4))) -1 (nil))

(insn 29 28 30 930921-1.c:4 (set (reg:SI 52)
        (const_int 1 [0x1])) -1 (nil))

(jump_insn 30 29 31 930921-1.c:4 (set (pc)
        (if_then_else (ltu (subreg:SI (reg:DI 51) 4)
                (subreg:SI (reg:DI 45 [ ivtmp$55 ]) 4))
            (label_ref 32)
            (pc))) -1 (nil))

(insn 31 30 32 930921-1.c:4 (set (reg:SI 52)
        (const_int 0 [0x0])) -1 (nil))

(code_label 32 31 33 6 "" [0 uses])

(insn 33 32 34 930921-1.c:4 (set (subreg:SI (reg:DI 51) 0)
        (plus:SI (subreg:SI (reg:DI 45 [ ivtmp$55 ]) 0)
            (subreg:SI (reg:DI 50) 0))) -1 (nil))

(insn 34 33 35 930921-1.c:4 (set (reg:SI 53)
        (plus:SI (reg:SI 52)
            (subreg:SI (reg:DI 51) 0))) -1 (nil))

(insn 35 34 36 930921-1.c:4 (set (subreg:SI (reg:DI 51) 0)
        (reg:SI 53)) -1 (nil))

(insn 36 35 0 930921-1.c:4 (set (reg:DI 45 [ ivtmp$55 ])
        (reg:DI 51)) -1 (expr_list:REG_EQUAL (plus:DI (reg:DI 45 [ ivtmp$55 ])
            (reg:DI 50))
        (nil)))

The failing assertion in get_biv_step() is:

  gcc_assert ((*inner_mode == *outer_mode) != (*extend != UNKNOWN));

The outer_mode is DImode; the inner_mode is SImode; and extend is
UNKNOWN, since there are no SIGN_EXTEND or ZERO_EXTEND operations
involved here.  Is this code intended to work for DImode IVs when
the machine doesn't directly support DImode operations?  I don't know
if the problem is in this loop-iv.c code or whether it ought not
recognize the DImode induction variable in the first place.

Help?