On Fri, Jul 15, 2011 at 9:01 AM, Uros Bizjak <ubiz...@gmail.com> wrote:
> On Fri, Jul 15, 2011 at 5:44 PM, H.J. Lu <hjl.to...@gmail.com> wrote:
>
>>>>>> TARGET_MEM_REF only works on ptr_mode. That means base and index parts
>>>>>> of x86 address operand in x32 mode may be in ptr_mode. This patch
>>>>>> supports 32bit base and index parts in x32 mode. OK for trunk?
>>>>>>
>>>>>> Thanks.
>>>>>>
>>>>>>
>>>>>> H.J.
>>>>>> ---
>>>>>> 2011-07-09 H.J. Lu <hongjiu...@intel.com>
>>>>>>
>>>>>> * config/i386/i386.c (ix86_simplify_base_index_disp): New.
>>>>>> (ix86_decompose_address): Support 32bit address in x32 mode.
>>>>>> (ix86_legitimate_address_p): Likewise.
>>>>>> (ix86_fixup_binary_operands): Likewise.
>>>>>
>>>>> Why don't you handle translations in TARGET_LEGITIMIZE_ADDRESS (or
>>>>> maybe also LEGITIMIZE_RELOAD_ADDRESS) ?
>>>>>
>>>>
>>>> It is because ix86_decompose_address is also called from:
>>>>
>>>> predicates.md: ok = ix86_decompose_address (op, &parts);
>>>> predicates.md: ok = ix86_decompose_address (op, &parts);
>>>> predicates.md: ok = ix86_decompose_address (XEXP (op, 0), &parts);
>>>> predicates.md: ok = ix86_decompose_address (XEXP (op, 0), &parts);
>>>> predicates.md: ok = ix86_decompose_address (XEXP (op, 0), &parts);
>>>
>>> Yes, but you should legitimize the address created by reload before it
>>> enters into predicates.
>>>
>>> So, the questions are:
>>>
>>> + (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)))
>>> +
>>> + We translate it into
>>> +
>>> + (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])))
>>>
>>> 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
H.J.
