Hello Venkat, On Wed, Apr 29, 2015 at 09:25:21AM +0000, Kumar, Venkataramanan wrote: > 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.
> 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. Right. It would be good if you could find out for what targets it matters. The thing is, if a target expects only the patterns as combine used to make them, it will regress (as you've seen on aarch64); but it will regress _silently_. Which isn't so nice. > But before that I wanted to check if the assumption in combiner, can > simply be removed ? Seeing for what targets / patterns it makes a difference would tell us the answer to that, too :-) I'll run some tests with and without your patch. Segher
