Comments

Hello!
Attached patch implements addr32 prefixed addresses for x86_64
targets, where memory locations are accessed with 32bit base and index
registers in the form (zero_extend:DI (... SImode registers ...)).
The optimization rarely (if at all) triggers on x86_64, but is very
important on x32 (see [1]), where many LEAs get moved into addresses
of the operators.
Of some interest is inability of reload to fix-up its own generated
moves for offsetable memory operand constraint "o", as it happens with
TImode moves. See [2] for further analysis and [3] for the workaround.
2011-08-08 Uros Bizjak <ubizjak@gmail.com>
PR target/49781
* config/i386/i386.c (ix86_decompose_address): Allow zero-extended
SImode addresses.
(ix86_print_operand_address): Handle zero-extended addresses.
(memory_address_length): Add length of addr32 prefix for
zero-extended addresses.
(ix86_secondary_reload): Handle moves to/from double-word general
registers from/to zero-extended addresses.
* config/i386/predicates.md (lea_address_operand): Reject
zero-extended operands.
Patch was bootstrapped and regression tested on x86_64-pc-linux-gnu
{,-m32}. Additionally, H.J. tested the patch on x32 target with GCC
bootstrap/regression tests, build of glibc (+regression tests) and
SPEC2000/2006.
Patch was committed to mainline SVN.
BTW: There is a strange optimization in combine pass, where
zero-extended address is converted on-the-fly to:
Trying 9 -> 10:
Failed to match this instruction:
(... (and:DI (subreg:DI (plus:SI (ashift:SI (reg/v:SI 63 [ i ])
(const_int 2 [0x2]))
(subreg:SI (reg/v/f:DI 62 [ a ]) 0)) 0)
(const_int 4294967295 [0xffffffff]))
...)
While it is easy to add a pattern recognizer for this RTX to
ix86_decompose_address/ix86_legitimate_address_p, I would like to
understand the purpose of the conversion better and eventually fix it
in combine pass.
[1] http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49781
[2] http://gcc.gnu.org/ml/gcc/2011-08/msg00129.html
[3] http://gcc.gnu.org/ml/gcc/2011-08/msg00157.html
Uros.