http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53352

             Bug #: 53352
           Summary: Incorrect CSE optimization on RTL expressions with a
                    paradoxical subreg
    Classification: Unclassified
           Product: gcc
           Version: 4.8.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: rtl-optimization
        AssignedTo: unassig...@gcc.gnu.org
        ReportedBy: mead...@codesourcery.com
              Host: GNU/Linux
            Target: arm-none-linux-gnueabi


The attached reproduction case exhibits what I believe to be a bug
in the CSE pass.  The problem can be reproduced from the mainline
at r187470.  The compiler was built for arm-none-linux-gnueabi
and the reproduction case was compiled with -O3.

Out of the gate the expanded RTL of interest looks like:

(insn 12 11 13 3 (set (reg:SI 140)
        (lshiftrt:SI (reg/v:SI 135 [ tmp1 ])
            (const_int 16 [0x10])))
     (nil))

(insn 13 12 14 3 (set (reg:QI 141)
        (subreg:QI (reg:SI 140) 0))
     (nil))

(insn 14 13 15 3 (set (reg:SI 142)
        (subreg:SI (reg:QI 141) 0))
     (nil))

(insn 15 14 16 3 (set (reg:SI 134 [ tmp1$2 ])
        (and:SI (reg:SI 142)
            (const_int 255 [0xff])))
     (nil))

...

(insn 29 28 30 3 (set (reg:SI 0 r0)
        (const_int 0 [0]))
     (nil))

after "cse1" things look like:

(insn 12 11 13 2 (set (reg:SI 140)
        (const_int 65280 [0xff00]))
     (nil))

(insn 13 12 14 2 (set (reg:QI 141)
        (subreg:QI (reg:SI 140) 0))
     (expr_list:REG_EQUAL (const_int 0 [0])
        (nil)))

;; This is *not* equal to zero because the upper
;; two bytes are undefined.
(insn 14 13 15 2 (set (reg:SI 142)
        (subreg:SI (reg:QI 141) 0))
     (expr_list:REG_EQUAL (const_int 0 [0])
        (nil)))

(insn 15 14 16 2 (set (reg:SI 134 [ tmp1$2 ])
        (reg:SI 142))
     (expr_list:REG_EQUAL (const_int 0 [0])
        (nil)))

...

(insn 29 28 30 2 (set (reg:SI 0 r0)
        (reg:SI 142))
     (expr_list:REG_EQUAL (const_int 0 [0])
        (nil)))

I believe the REG_EQUAL note on the set involving a paradoxical subreg
is incorrect.  It eventually causes 0xFF00 to be passed to the function
'foo'.

I doesn't look like 'equiv_constant' handles the paradoxical subreg case
correctly.  I fixed it as follows and am testing the patch now:

Index: gcc/cse.c
===================================================================
--- gcc/cse.c   (revision 187470)
+++ gcc/cse.c   (working copy)
@@ -3786,8 +3786,11 @@
            }
        }

-      /* Otherwise see if we already have a constant for the inner REG.  */
+      /* Otherwise see if we already have a constant for the inner REG.
+        Don't bother with paradoxical subregs because we have no way
+        of knowing what the upper bytes are.  */
       if (REG_P (SUBREG_REG (x))
+         && (GET_MODE_SIZE (mode) <= GET_MODE_SIZE (imode))
          && (new_rtx = equiv_constant (SUBREG_REG (x))) != 0)
         return simplify_subreg (mode, new_rtx, imode, SUBREG_BYTE (x));

Reply via email to