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

[Uros Bizjak <ubizjak@gmail.com>]

On Fri, Jul 15, 2011 at 5:44 PM, H.J. Lu <hjl.tools@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.lu@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?

Uros.