On Sun, Oct 29, 2017 at 10:28 AM, Uros Bizjak <ubiz...@gmail.com> wrote:
> 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.
Make sense.
>>> 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 ...".
>
I think x86 displacement check should be put in a function and used by
both x86_64_immediate_operand and legitimate_pic_address_disp_p.
--
H.J.
