Patchwork [rtl-optimization] : Fix PR54457, [x32] Fail to combine 64bit index + constant

Hello!

Attached patch fixes the combine deficiency, where combine is not able
to recognize combination of:

Trying 6 -> 8:
Failed to match this instruction:
(set (reg:QI 66)
    (mem/j:QI (plus:SI (subreg:SI (plus:DI (reg/v:DI 62 [ position ])
                    (const_int 1 [0x1])) 0)
            (symbol_ref:SI ("array") [flags 0x40]  <var_decl
0x7ffff19ad260 array>)) [0 array S1 A8]))

This should be a valid address, but the RTX is not accepted in
ix86_decompose_address since
we have two displacements here. Combine should simplify this RTX to:

(set (reg:QI 68)
    (mem/j:QI (plus:SI (subreg:SI (reg/v:DI 62 [ position ]) 0)
            (const:SI (plus:SI (symbol_ref:SI ("array") [flags 0x40]
<var_decl 0x7f8d1bc41390 array>)
                    (const_int 1 [0x1])))) [0 array S1 A8]))


as is the case with -m32 (but rejected for 32bit targets in
ix86_address_subreg_operand for unrelated reason).

The solution is, to transform operands of PLUS and MINUS RTX in the
form of (subreg:M (op:N A C) 0) to (op:M (subreg:N (A 0)) C), as is
done for standalone subreg operation in 32bit case.  This
transformation generates canonical (plus:M (plus:M (subreg:N (A 0) C1)
C2)) RTXes that can be recognized and further optimized by
simplify_plus_minus.

The effect of the patch on following testcase (-O2 -mx32 -maddres-mode=short):

--cut here--
extern char array[40];

char foo (long long position)
{
  return array[position + 1];
}
--cut here--

 foo:
-       addq    $1, %rdi
-       movzbl  array(%edi), %eax
+       movzbl  array+1(%edi), %eax
        ret

The patch is effective also for -fpic:

 foo:
        movl    array@GOTPCREL(%rip), %eax
-       addq    $1, %rdi
-       movzbl  (%eax,%edi), %eax
+       movzbl  1(%eax,%edi), %eax
        ret

Generated code for vanilla 32bit and 64bit targets is unchanged.

2012-09-25  Uros Bizjak  <ubizjak@gmail.com>

	PR rtl-optimization/54457
	* combine.c (combine_simplify_rtx) <RTX_COMM_ARITH, RTX_BIN_ARIT>:
	For PLUS and MINUS, convert plus_minus_operand_p operands in
	the form of (subreg:M (op:N A C) 0) to (op:M (subreg:N (A 0)) C).
	* simplify-rtx.c (plus_minus_operand_p): Make global.
	* rtl.h (plus_minus_operand_p): Declare.

testsuite/ChangeLog:

2012-09-25  Uros Bizjak  <ubizjak@gmail.com>

	PR rtl-optimization/54457
	* gcc.target/i386/pr54457.c: New test.

Patch was bootstrapped and regression tested on x86_64-pc-linux-gnu
{,-m32}, also on x32 target by H.J [1].

OK for mainline?

[1] http://gcc.gnu.org/ml/gcc-testresults/2012-09/msg02448.html

Uros.

Uros Bizjak <ubizjak@gmail.com> writes:
> The solution is, to transform operands of PLUS and MINUS RTX in the
> form of (subreg:M (op:N A C) 0) to (op:M (subreg:N (A 0)) C), as is
> done for standalone subreg operation in 32bit case.

I agree (subreg:M (op:N A C) 0) to (op:M (subreg:N (A 0)) C) is
a good transformation, but why do we need to handle as special
the case where the subreg is itself the operand of a plus or minus?
I think it should happen regardless of where the subreg occurs.

On the face of it, this feels like something that could legimately
go in simplify_subreg.

Richard

> I agree (subreg:M (op:N A C) 0) to (op:M (subreg:N (A 0)) C) is
> a good transformation, but why do we need to handle as special
> the case where the subreg is itself the operand of a plus or minus?
> I think it should happen regardless of where the subreg occurs.

Don't we need to restrict this to the low part though?