Re: [RFC]: Remove Mem/address type assumption in combiner

[Segher Boessenkool <segher@kernel.crashing.org>]

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