On Sun, Oct 29, 2017 at 5:55 PM, H.J. Lu <hjl.to...@gmail.com> wrote:
> On Sun, Oct 29, 2017 at 12:38 AM, Uros Bizjak <ubiz...@gmail.com> wrote:
>> Hello!
>>
>> split_double_mode tries to split TImode address:
>>
>> (insn 10 2 11 2 (set (reg/i:TI 0 ax)
>>         (mem/u/c:TI (const:DI (unspec:DI [
>>                         (symbol_ref:DI ("_ZZ7tempDirvE5cache") [flags 0x2a])
>>                     ] UNSPEC_NTPOFF)) [1 cache+0 S16 A64 AS1]))
>> to:
>>
>> (const:DI (unspec:DI [
>>                 (symbol_ref:DI ("_ZZ7tempDirvE5cache") [flags 0x2a])
>>             ] UNSPEC_NTPOFF))
>>
>> and
>>
>> (const:DI (plus:DI (unspec:DI [
>>                 (symbol_ref:DI ("_ZZ7tempDirvE5cache") [flags 0x2a])
>>             ] UNSPEC_NTPOFF)
>>         (const_int 8 [0x8])))
>>
>> but the later RTX is not recognized as a valid address.
>>
>> Attached patch allows offsetted UNSPEC_DTPOFF/UNSPEC_NTPOFF
>> relocations in legitimate_pic_address_disp_p. In fact, these are
>> already allowed in x86_64_immediate_operand, with the immediate
>> limited to SImode values.
>>
>> 2017-10-29  Uros Bizjak  <ubiz...@gmail.com>
>>
>>     PR target/82725
>>     * config/i386/i386.c (legitimate_pic_address_disp_p): Allow
>>     UNSPEC_DTPOFF and UNSPEC_NTPOFF with SImode immediate offset.
>>
>> testsuite/ChangeLog:
>>
>> 2017-10-29  Uros Bizjak  <ubiz...@gmail.com>
>>
>>     PR target/82725
>>     * g++.dg/pr82725.C: New test.
>>
>> Bootstrapped and regression tested on x86_64-linux-gnu {,-m32}.
>>
>> Jakub, HJ, do you have any comments on the patch?
>>
>> Uros.
>
> 2 questions:
>
> 1.  Why isn't legitimate_pic_address_disp_p a static function?

Looks like it was used from .md files in the past (it still has a
prototype in i386-protos.h). It can be made static, but I don't want
to mix cleanups and bugfixes in the same patch.

> 2.  Should we add a legitimate_address_disp_p function to
> handle both PIC and non-PIC displacement which is also
> used by x86_64_immediate_operand?

There are opportunities in x86 PIC code for a considerable cleanup.
The code looks like x86_64 part was bolted on the i386 code, with some
parts of TARGET_64BIT code duplicating generic x86 code.

Uros.

Reply via email to