On Mon, Mar 26, 2012 at 10:41 AM, H.J. Lu <hjl.to...@gmail.com> wrote:
> On Mon, Mar 26, 2012 at 10:25 AM, Uros Bizjak <ubiz...@gmail.com> wrote:
>> Hello!
>>
>> In a corner case of a reload, reload pass can generate partially
>> reloaded address, where not all registers get allocated to a hard reg.
>> When this address is checked with ix86_legitimate_address, it is
>> rejected, since in strict mode, pseudos are not valid address
>> registers. So, reload tries to legitimize following (partially
>> invalid) address:
>>
>> (plus:DI (plus:DI (unspec:DI [(const_int 0 [0])] UNSPEC_TP)
>> (reg:DI 97))
>> (reg:DI 2 cx))
>>
>> via generic way by pushing all components into a register, forming
>> (even more invalid) address that involves three registers (r8, r9 and
>> rcx):
>>
>> (insn 52 78 53 5 (set (mem/j:QI (plus:DI (plus:DI (reg:DI 37 r8)
>> (reg:DI 38 r9))
>> (reg:DI 2 cx [orig:98 D.1709 ] [98])) [0 foo S1 A8])
>> (reg:QI 1 dx [100])) /tmp/x.c:12 66 {*movqi_internal}
>> (nil))
>>
>> BTW: x86 declares MAX_REGISTER_PER_ADDRESS to 2...
>>
>> Attached patch fixes this situation by (partially) reloading only
>> remaining pseudo(s), leaving UNSPEC in the address RTX.
>>
>> 2012-03-26 Uros Bizjak <ubiz...@gmail.com>
>>
>> PR target/52698
>> * config/i386/i386-protos.h (ix86_legitimize_reload_address):
>> New prototype.
>> * config/i386/i386.h (LEGITIMIZE_RELOAD_ADDRESS): New define.
>> * config/i386/i386.c: Include reload.h.
>> (ix86_legitimize_reload_address): New function.
>>
>> testsuite/ChangeLog:
>>
>> 2012-03-26 Uros Bizjak <ubiz...@gmail.com>
>> H.J. Lu <hongjiu...@intel.com>
>>
>> PR target/52698
>> * gcc.target/i386/pr52698.c: New test.
>>
>> The patch was bootstrapped and regression tested on x86_64-pc-linux-gnu
>> {,-m32}.
>>
>> Since fixing reload issues is some kind of black magic, I'd like to
>> ask Ulrich and Richard for their opinion on this approach.
>>
>> H.J., can you please test this fix on x32 testsuite for both address modes?
>>
>
> I am on it.
There are no regressions in gcc x32 testsuite nor glibc tests for
both address modes. But I didn't check code quality nor SPEC CPU
performance.
--
H.J.
