diff mbox

[PR,rtl-optimization/42522] Incorrect simplification of ZERO_EXTRACT and SIGN_EXTRACT by cse

Message ID 552E5912.8050801@redhat.com
State New
Headers show

Commit Message

Jeff Law April 15, 2015, 12:26 p.m. UTC 
I've bootstrapped and regression tested this patch on x86_64-linux-gnu 
and committed it to the trunk.

The bug is latent on the reported target (m68k), so no testcase.


-------- Forwarded Message --------
Subject: [PATCH][PR rtl-optimization/42522] Incorrect simplification of 
ZERO_EXTRACT and SIGN_EXTRACT by cse
Date: Fri, 06 Feb 2015 15:05:31 -0700
From: Jeff Law <law@redhat.com>
To: gcc-patches <gcc-patches@gcc.gnu.org>

This bug has gone latent on the trunk; however, the problem still
remains that cse will incorrectly simplify a ZERO/SIGN_EXTRACT in some
cases.

ZERO/SIGN_EXTRACT are somewhat special in that if they are extracting
from a memory operand, that memory operand will always have QImode
regardless of the size of the extracted field.

ie, the mode of the MEM in a ZERO/SIGN_EXTRACT does not really mean
anything and the ZERO/SIGN_EXTRACT can read bits beyond QImode.

So given a (mem:QI x) with an equivalence to (const_int 0) in the hash
tables.  If we have an extraction like

(zero_extract:SI (mem:QI x) (const_int 0) (const_int 24))

CSE will substitute (const_int 0) for the MEM in the extraction resulting in

(zero_extract:SI (const_int 0) (const_int 0) (const_int 24))

Which simplifies to (const_int 0)

For REGs, the mode is the same as the operand of the insv/extv pattern,
and may (or may not) more closely resemble reality depending on the target.

The safe thing to do in CSE is to lookup the ZERO/SIGN_EXTRACT as a whole.

Given the bug is latent and not currently a regression this will need to
wait for the next stage1 development cycle.
diff mbox

Patch

diff --git a/gcc/cse.c b/gcc/cse.c
index f7b477c..8ab48c4 100644
--- a/gcc/cse.c
+++ b/gcc/cse.c
@@ -3178,6 +3178,15 @@  fold_rtx (rtx x, rtx insn)
     {
     case MEM:
     case SUBREG:
+    /* The first operand of a SIGN/ZERO_EXTRACT has a different meaning
+       than it would in other contexts.  Basically its mode does not
+       signify the size of the object read.  That information is carried
+       by size operand.    If we happen to have a MEM of the appropriate
+       mode in our tables with a constant value we could simplify the
+       extraction incorrectly if we allowed substitution of that value
+       for the MEM.   */
+    case ZERO_EXTRACT:
+    case SIGN_EXTRACT:
       if ((new_rtx = equiv_constant (x)) != NULL_RTX)
         return new_rtx;
       return x;