On Tue, Jul 19, 2011 at 1:25 PM, Richard Sandiford <richard.sandif...@linaro.org> wrote:
>> On Sat, Jul 16, 2011 at 6:47 PM, H.J. Lu <hjl.to...@gmail.com> wrote: >>>>> Yes, this is an example from PR I am referring to. Did you try to >>>>> define LEGITIMIZE_RELOAD_ADDRESS? It is supposed to fix this. >>>>> >>>> >>>> They make things even more complex. ix86_simplify_base_index_disp >>>> is called after reload is done since we can do this translation safely >>>> only on hard registers, not on pseudo registers. >>>> >>> >>> Hi Uros, >>> >>> The current implementation has been tested extensively. I'd like to keep >>> it ASIS so that we can have a working x32 support. We will revisit it >>> later: >>> >>> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49765 >>> >>> after we have a working x32 GCC. >> >> This can not be only my decision, I have CCd other x86 maintainers and >> RMs for their opinion on this question. > > FWIW, I agree with you that things like: > > (set (reg:SI 40 r11) > (plus:SI (plus:SI (mult:SI (reg:SI 1 dx) > (const_int 8)) > (subreg:SI (plus:DI (reg/f:DI 7 sp) > (const_int CONST1)) 0)) > (const_int CONST2))) > > do not look like things that should ever enter the insn stream. > They're liable to confuse other code besides the x86 predicates. > The target of the conversion: > > (set (reg:SI 40 r11) > (plus:SI (plus:SI (mult:SI (reg:SI 1 dx) > (const_int 8)) > (reg/f:SI 7 sp)) > (const_int [CONST1 + CONST2]))) > > looks like the generally preferred form. It isn't an x32-ism. > > LEGITIMIZE_RELOAD_ADDRESS is supposed to be for optimisation only, > not correctness. Why doesn't reload have enough information to > generate the correct form itself? Please see the solution at [1]. The problem was that x86 target allowed SImode subregs of DImode operations (i.e. PLUS). When these are rejected, everything works as expected. IMO, LEGITIMIZE_RELOAD_ADDRESS can not optimize resulting RTX, as shown in [1]. [1] http://gcc.gnu.org/ml/gcc-patches/2011-07/msg01427.html Uros.
