[RFA:] Fix gcc.c-torture/execute/20020720-1.x and further analysis

[Hans-Peter Nilsson <hp at bitrange dot com>]

Request for approval since this also changes the reason-for-
failure comment, not just adding MMIX to the bunch of XFAIL
targets.

I do think the abs-optimization is misplaced since it depends on
the machine description and GCC to not split up the (abs(x) <
0.0) expression into too many parts.  This optimization (if done
at the RTL level at all) would be better placed in ifcvt.c;
that'd supposedly let the optimization happen for more targets.

Roger Sayle sent a patch to add MMIX to the XFAIL targets, but I
preferred to investigate first.  I looked at what happens for
MMIX in 20020720-1.c, and it matches the effects of paragraph 2
in the .x file, so it was thankfully not a "new" cause of
failure.

But I really dislike the wording in that comment: the machine
description is precise (in these parts, at least), it's *not*
obfuscated.  To the contrary, tweaking the md to appease the
code for the abs-optimization would be to obfuscate it.  In
order to test the correctness of the description in the comment,
I did obfuscate mmix.md to get a floating-point comparison insn
with 0.0 as an operand.  That made the optimization trigger, so
the observations were right from which the conclusions come with
which I don't agree.  (Huh, *that* came out snotty if anything!
:-)  Oh well, not a native speaker and all that.  At least the
last word in the sentence isn't a preposition. ;-)

	* gcc.c-torture/execute/20020720-1.x: Skip test on
	mmix-knuth-mmixware.  Correct comment.

Index: 20020720-1.x
===================================================================
RCS file: /cvs/gcc/gcc/gcc/testsuite/gcc.c-torture/execute/20020720-1.x,v
retrieving revision 1.1
diff -p -c -r1.1 20020720-1.x
*** 20020720-1.x	26 Jul 2002 02:38:42 -0000	1.1
--- 20020720-1.x	31 Aug 2002 13:35:09 -0000
***************
*** 1,15 ****
  # The following targets fail 20020720-1.c for several reasons:
  # (1) They implement floating point instructions via software, or
! # (2) Their machine descriptions obfuscate the "abs(x) < 0.0" comparison.
! #     For example, 1 insn performs abs, 1 insn loads 0.0, 1 insn sets
! #     CCmode flags based upon the FP comparison, and a 4th insn makes
! #     a conditional branch based upon the appropriate bits in the flags.
! #     If the intermediate comparison can't be recognized, the combiner
! #     is unable to optimize all four RTL instructions simultaneously.
!
  if { [istarget "powerpc-*-*"] || [istarget "rs6000-*-*"] \
       || [istarget "mips*-*-*"] || [istarget "xtensa-*-*"] \
!      || [istarget "sh-*-*"] } {
      return 1
  }

--- 1,17 ----
  # The following targets fail 20020720-1.c for several reasons:
  # (1) They implement floating point instructions via software, or
! # (2) The "abs(x) < 0.0" comparison is split up in too many intermediate
! #     insns for combine to handle -- it can handle max three insns
! #     simultaneously.  For example, for RISCy machines it is common that 1
! #     insn performs abs, 1 insn loads 0.0, 1 insn sets CCmode flags based
! #     upon the FP comparison, and a 4th insn makes a conditional branch
! #     based upon the appropriate bits in the flags.  On the other hand, if
! #     for example the comparison insn takes 0.0 as an operand, the
! #     combiner is able to see all intermediate instructions simultaneously
! #     and can make the optimization.
  if { [istarget "powerpc-*-*"] || [istarget "rs6000-*-*"] \
       || [istarget "mips*-*-*"] || [istarget "xtensa-*-*"] \
!      || [istarget "sh-*-*"] || [istarget "mmix-*-*"] } {
      return 1
  }


brgds, H-P