On Sun, Oct 29, 2017 at 6:25 PM, Uros Bizjak <ubiz...@gmail.com> wrote:
> 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.
That is, "... opportunities in x86 relocation handling code ...".
Uros.
