This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: PATCH [5/n] X32: Supprot 32bit address
On Fri, Jul 15, 2011 at 9:09 AM, Uros Bizjak <ubizjak@gmail.com> wrote:
> On Fri, Jul 15, 2011 at 6:07 PM, H.J. Lu <hjl.tools@gmail.com> wrote:
>
>>>>> If the first form of the address is not OK (it does not represent the
>>>>> hardware operation), then it should not enter into the insn stream.
>>>>> This means, that it should be fixed ("legitimized") to second form by
>>>>> appropriate function (it looks that LEGITIMIZE_RELOAD_ADDRESS should
>>>>> fix it, since the incorrect address is generated by IRA/reload). After
>>>>> this operation, various predicates, based on ix86_decompose_address
>>>>> will start to work, since they will decompose valid memory addresses.
>>>>>
>>>>
>>>> IRA/.RELOAD isn't prepared to deal with it and it just ICEs. ?I opened
>>>> a few GCC bugs on this.
>>>>
>>>> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47744
>>>>
>>>> is one of them. ?That is why I went this route.
>>>
>>> Hm, but it crashed in postreload pass since the address was not in the
>>> legitimate form. ?This is exactly what LEGITIMIZE_RELOAD_ADDRESS
>>> fixes. Did you try to go this route?
>>>
>>
>> It ran into various ICEs like:
>>
>> /export/build/gnu/gcc-x32/build-x86_64-linux/gcc/xgcc
>> -B/export/build/gnu/gcc-x32/build-x86_64-linux/gcc/ -S -o m.s -mx32 -std=gnu99
>> -O2 -fPIC ? ?m.i
>> m.i: In function \u2018__kernel_rem_pio2\u2019:
>> m.i:18:1: error: insn does not satisfy its constraints:
>> (insn 108 106 186 3 (set (reg:SI 40 r11 [207])
>> ? ? ? ?(plus:SI (plus:SI (mult:SI (reg:SI 1 dx [205])
>> ? ? ? ? ? ? ? ? ? ?(const_int 8 [0x8]))
>> ? ? ? ? ? ? ? ?(subreg:SI (plus:DI (reg/f:DI 7 sp)
>> ? ? ? ? ? ? ? ? ? ? ? ?(const_int 208 [0xd0])) 0))
>> ? ? ? ? ? ?(const_int -160 [0xffffffffffffff60]))) m.i:3 251 {*lea_1_x32}
>> ? ? (nil))
>> m.i:18:1: internal compiler error: in reload_cse_simplify_operands, at
>> postreload.c:403
>> Please submit a full bug report,
>> with preprocessed source if appropriate.
>> See <http://gcc.gnu.org/bugs.html> for instructions.
>> make: *** [m.s] Error 1
>
> 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.
>
>
I will take a look.
Thanks.
--
H.J.