ix86 code generation bug -march=pentiumpro

[Jim Wilson]

I have taken an initial look into this.

The problem is that the movsicc_1 pattern needs an input reload.  However,
since it is a cc0 user, input reloads can not work (they will clobber the
condition codes), and should not be allowed.  find_reloads has code to
detect this, but it falls through the cracks because the input reload
actually comes from find_reloads_address, which doesn't know about input/output
reload restrictions.

I think this is a general problem with the x86 integer mov*cc patterns.
Even if one only uses register constraints, you still need an input reload
if an input pseudo gets allocated to a stack slot.  I think the only safe
way to write conditional move insn patterns for the x86 is to write a pattern
that emits both the compare and conditional move, which does not get split
until after reload has completed.

Incidentally, the FP conditional move insns were recently disabled for the
same reason, i.e. they required impossible input reloads.

I think the only reasonable short term solution is to also disable the
integer conditional move insn patterns until they are rewritten.

Using the gcc 2.8.1 conditional move patterns instead of the current 
patterns makes this problem go away because it eliminates the memory
constraint that was causing this testcase to fail, but I don't think it
will solve the general problem.

Jim