Re: PR c/8068

[Roger Sayle <roger at www dot eyesopen dot com>]

It looks like the 2003-02-16 patch to fix PR c/8068 has inadvertantly
disabled GCC's ability to constant fold the expression  (2*x)/2.

http://gcc.gnu.org/ml/gcc-patches/2003-02/msg01311.html

The culprit is Arend's original hunk at line 4332 of fold-const.c:

+      /* Arrange for the code below to simplify two constants first.  */
+      if (TREE_CODE (op1) == INTEGER_CST && TREE_CODE (op0) != INTEGER_CST)
+       {
+         tree tmp = op0;
+         op0 = op1;
+         op1 = tmp;
+       }

      /* ... fall through ...  */

    case TRUNC_DIV_EXPR:  case CEIL_DIV_EXPR:  case FLOOR_DIV_EXPR:
    case ROUND_DIV_EXPR:  case EXACT_DIV_EXPR:
      /* If we can extract our operation from the LHS, do so and return a
         new operation.  Likewise for the RHS from a MULT_EXPR.  Otherwise,
         do something only if the second operand is a constant.  */


Unfortunately, almost immediately following at line 4355 is a test
that avoids attempting any further optimizations in op1 is not a
constant.  You'll notice that the hunk above specifically swaps the
operands into the reverse order from the one the rest of the code is
expecting.


I suspect that Richard Henderson's part of this patch, that limits
the extract_muldiv is sufficient on its own to fix the possible
performance problems.  Alternatively, we could just add some additional
logic to the tests immediately following to simplify swap the order
that we try to apply transformations if op1 is constant.

Roger
--
Roger Sayle,                         E-mail: roger at eyesopen dot com
OpenEye Scientific Software,         WWW: http://www.eyesopen.com/
Suite 1107, 3600 Cerrillos Road,     Tel: (+1) 505-473-7385
Santa Fe, New Mexico, 87507.         Fax: (+1) 505-473-0833