This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: PATCH [5/n] X32: Supprot 32bit address


On Tue, Jul 19, 2011 at 1:25 PM, Richard Sandiford
<richard.sandiford@linaro.org> wrote:

>> On Sat, Jul 16, 2011 at 6:47 PM, H.J. Lu <hjl.tools@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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]