| Message ID | 56698DD5.3010105@arm.com |
|---|---|
| State | New |
| Headers | show |
diff --git a/gcc/combine.c b/gcc/combine.c index 7d4ffbcc766113c0af1c903f3d0dadbe74dec7fa..2628e1a437c2cd63d439a3ad28d1799b8c679be3 100644 --- a/gcc/combine.c +++ b/gcc/combine.c @@ -11037,7 +11037,9 @@ change_zero_ext (rtx *src) if (BITS_BIG_ENDIAN) start = GET_MODE_PRECISION (mode) - size - start; - x = gen_rtx_LSHIFTRT (mode, XEXP (x, 0), GEN_INT (start)); + x = XEXP (x, 0); + if (start > 0) + x = gen_rtx_LSHIFTRT (mode, x, GEN_INT (start)); } else if (GET_CODE (x) == ZERO_EXTEND && GET_CODE (XEXP (x, 0)) == SUBREG
Hi all, At the end of combine if it fails to recognise the patterns it produces it tries again after transforming all zero_extends and zero_extracts into and-immediate plus an LSHIFTRT if needed. However, it will construct an LSHIFTRT inside the AND even if the shift distance is 0, which can hurt recognisability. This patch fixes that by not creating the LSHIFRT of zero. I hit this when I was experimenting with some new backend patterns and other unrelated combine changes, so I don't have a testcase that shows this on a clean trunk, but I believe this could hurt recognisability in the future. Bootstrapped and tested on arm, aarch64, x86_64. I didn't see any codegen differences with clean trunk on aarch64 SPEC2006. I'm okay with delaying this for next stage 1 if people prefer, though I think it's pretty low risk. What do people think? Kyrill 2015-12-10 Kyrylo Tkachov <kyrylo.tkachov@arm.com> * combine.c (change_zero_ext): Do not create a shift of zero length.