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.tkac...@arm.com>
* combine.c (change_zero_ext): Do not create a shift of zero length.
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
