Hi all,

For this PR I want to teach combine to deal with unrecognisable patterns that contain a sub-expression like
(x + x) by transforming it into (x << 1) and trying to match the result. This is because some instruction
sets like arm and aarch64 can combine shifts with other arithmetic operations or have shifts in their RTL representation
of more complex operations (like the aarch64 UBFIZ instruction which can be expressed as a zero_extend+ashift pattern).

Due to a change in rtx costs for -mcpu=cortex-a53 in GCC 5 we no longer expand an expression like x * 2 as x << 1
but rather as x + x, which hurts combination opportunities dues to this deficiency.

This patch addresses the issue in the recog_for_combine function in combine.c in a similar way to the change_zero_ext
trick. That is, if it recog_for_combine fails to match a pattern it replaces all instances of x + x in the
rtx with x << 1 and tries again.

This way I've been able to get combine to more aggressively generate the arithmetic+shift forms of instructions for
-mcpu=cortex-a53 on aarch64 as well as instructions like ubfiz and sbfiz that contain shift-by-immediate sub-expressions.

This patch shouldn't affect rtxes that already match, so it should have no fallout on other cases.

Bootstrapped and tested on arm, aarch64, x86_64.

For the testcase:
int
foo (int x)
{
   return (x * 2) & 65535;
}

int
bar (int x, int y)
{
   return (x * 2) | y;
}

with -O2 -mcpu=cortex-a53 for aarch64 we now generate:
foo:
         ubfiz   w0, w0, 1, 15
         ret

bar:
         orr     w0, w1, w0, lsl 1
         ret

whereas without this patch we generate:
foo:
         add     w0, w0, w0
         uxth    w0, w0
         ret

bar:
         add     w0, w0, w0
         orr     w0, w0, w1
         ret


PR 68651 is a code quality regression for GCC 5 and GCC 6 that was introduced due to updated rtx costs
for -mcpu=cortex-a53 that affected expansion.  The costs changes were correct (to the extent that rtx
costs have any meaning) and I think this is a deficiency in combine that should be fixed.

I wouldn't propose to backport this to GCC 5.

P.S. For the ubfiz testcase above to combine successfully it needs an aarch64 rtx costs issue to be resolved
that I proposed a fix for in https://gcc.gnu.org/ml/gcc-patches/2015-12/msg00526.html.
Otherwise the backend wrongly rejects it on the grounds of wrong costs.

Is this ok for trunk once the costs issue at https://gcc.gnu.org/ml/gcc-patches/2015-12/msg00526.html
gets resolved?

Thanks,
Kyrill

2015-12-14  Kyrylo Tkachov  <kyrylo.tkachov@arm.com>

     PR rtl-optimization/68651
     * combine.c (change_shift_by_one): New function.
     (change_rtx_with_func): Likewise.
     (recog_for_combine): Use the above to transform reg + reg
     sub-expressions into reg << 1 within non-recognisable patterns
     and try to match the result.

2015-12-14  Kyrylo Tkachov  <kyrylo.tkachov@arm.com>

     PR rtl-optimization/68651
     * gcc.target/aarch64/pr68651_1.c: New test.