[2/2] rtl-optimization/113255 - avoid re-associating REG_POINTER MINUS

Message ID 20240201142142.3A12A3858005@sourceware.org
State New
Headers
Series [1/2] target/113255 - avoid REG_POINTER on a pointer difference |

Checks

Context Check Description
linaro-tcwg-bot/tcwg_gcc_build--master-arm success Testing passed
linaro-tcwg-bot/tcwg_gcc_check--master-arm success Testing passed
linaro-tcwg-bot/tcwg_gcc_build--master-aarch64 success Testing passed
linaro-tcwg-bot/tcwg_gcc_check--master-aarch64 success Testing passed

Commit Message

Richard Biener Feb. 1, 2024, 2:20 p.m. UTC
  The following avoids re-associating

 (minus:DI (reg/f:DI 119)
    (minus:DI (reg/f:DI 120)
        (reg/f:DI 114)))

into

 (minus:DI (plus:DI (reg/f:DI 114)
        (reg/f:DI 119))
    (reg/f:DI 120))

as that possibly confuses the REG_POINTER heuristics of RTL
alias analysis.  This happens to miscompile the PRs testcase
during DSE which expands addresses via CSELIB which eventually
simplifies what it substituted to.  The original code does
the innocent ptr - (ptr2 - ptr2'), bias a pointer by the
difference of two other pointers.

--

This is what I propose for the PR for branches, I have not made much
progress with fixing the fallout on the RTL alias analysis change
on trunk, so this is the alternative if we decide to revert that.

Bootstrapped and tested on x86_64-unknown-linux-gnu on the gcc-13
branch, bootstrapped after reverting of the previous fix on
x86_64-unknown-linux-gnu on trunk, testing is still ongoing there.

OK?  Any preference for trunk?

Thanks,
Richard.

	PR rtl-optimization/113255
	* simplify-rtx.cc (simplify_context::simplify_binary_operation_1):
	Do not re-associate a MINUS with a REG_POINTER op0.
---
 gcc/simplify-rtx.cc | 8 ++++++--
 1 file changed, 6 insertions(+), 2 deletions(-)
  

Patch

diff --git a/gcc/simplify-rtx.cc b/gcc/simplify-rtx.cc
index ee75079917f..0108d0aa3bd 100644
--- a/gcc/simplify-rtx.cc
+++ b/gcc/simplify-rtx.cc
@@ -3195,11 +3195,15 @@  simplify_context::simplify_binary_operation_1 (rtx_code code,
          canonicalize (minus A (plus B C)) to (minus (minus A B) C).
 	 Don't use the associative law for floating point.
 	 The inaccuracy makes it nonassociative,
-	 and subtle programs can break if operations are associated.  */
+	 and subtle programs can break if operations are associated.
+	 Don't use the associative law when subtracting a MINUS from
+	 a REG_POINTER as that can trick find_base_term into discovering
+	 the wrong base.  */
 
       if (INTEGRAL_MODE_P (mode)
 	  && (plus_minus_operand_p (op0)
-	      || plus_minus_operand_p (op1))
+	      || ((!REG_P (op0) || !REG_POINTER (op0))
+		  && plus_minus_operand_p (op1)))
 	  && (tem = simplify_plus_minus (code, mode, op0, op1)) != 0)
 	return tem;