On 04/29/2015 03:25 AM, Kumar, Venkataramanan wrote:
Hi Jeff/Segher,
When we see an RTX code with PLUS or MINUS then it is treated as MEM/address
type (we are inside address RTX).
Is there any significance on that assumption? I removed this assumption and
the test case in the PR 63949 passed.
When appearing inside a MEM, we have different canonicalization rules.
The comment in make_compound_operation clearly indicates that the
PLUS/MINUS support is a hack. However, I'm pretty sure it was strictly
for getting better code than for correctness.
One path forward is to properly track if we're in a MEM, at which point
the hack for PLUS/MINUS could probably just go away.
diff --git a/gcc/combine.c b/gcc/combine.c
index 5c763b4..945abdb 100644
--- a/gcc/combine.c
+++ b/gcc/combine.c
@@ -7703,8 +7703,6 @@ make_compound_operation (rtx x, enum rtx_code in_code)
but once inside, go back to our default of SET. */
next_code = (code == MEM ? MEM
- : ((code == PLUS || code == MINUS)
- && SCALAR_INT_MODE_P (mode)) ? MEM
: ((code == COMPARE || COMPARISON_P (x))
&& XEXP (x, 1) == const0_rtx) ? COMPARE
: in_code == COMPARE ? SET : in_code);
On X86_64, it passes bootstrap and regression tests.
But on Aarch64 the test in PR passed, but I got a few test case failures.
Tests that now fail, but worked before:
gcc.target/aarch64/adds1.c scan-assembler adds\tw[0-9]+, w[0-9]+, w[0-9]+, lsl 3
gcc.target/aarch64/adds1.c scan-assembler adds\tx[0-9]+, x[0-9]+, x[0-9]+, lsl 3
So that test seems to want to verify that you can generate a shift-add
type instruction. I suspect the others are similar. I'd be curious to
see the .combine dump as well as the final assembly for this test.
Which is a strong hint that we should be looking at target with
shift-add style instructions. ARM, AArch64, HPPA, x86 come immediately
to mind.
There are few patterns based on multiplication operations in Aarch64 backend
which are used to match with the pattern combiner generated.
Now those patterns have to be fixed to use SHIFTS. Also need to see any impact
on other targets.
But before that I wanted to check if the assumption in combiner, can simply
be removed ?
Given what I'm seeing now, I doubt it can simply be removed at this
point (which is a change in my position) since ports with these
shift-add style instructions have probably been tuned to work with
existing combine behaviour. We may need to do a deep test across
various targets to identify those affected and fix them.
jeff
