Re: [PATCH v2 2/2] LoongArch: When the code model is extreme, the symbol address is obtained through macro instructions regardless of the value of -mexplicit-relocs.

[chenglulu <chenglulu@loongson.cn>]

在 2024/1/19 下午4:51, chenglulu 写道:
>
> 在 2024/1/19 下午1:46, Xi Ruoyao 写道:
>> On Wed, 2024-01-17 at 17:57 +0800, chenglulu wrote:
>>>>> Virtual register 1479 will be used in insn 2744, but register 1479 
>>>>> was
>>>>> assigned the REG_UNUSED attribute in the previous instruction.
>>>>>
>>>>> The attached file is the wrong file.
>>>>> The compilation command is as follows:
>>>>>
>>>>> $ ./gcc/cc1 -fpreprocessed regrename.i -quiet -dp -dumpbase 
>>>>> regrename.c
>>>>> -dumpbase-ext .c -mno-relax -mabi=lp64d -march=loongarch64 -mfpu=64
>>>>> -msimd=lasx -mcmodel=extreme -mtune=loongarch64 -g3 -O2
>>>>> -Wno-int-conversion -Wno-implicit-int 
>>>>> -Wno-implicit-function-declaration
>>>>> -Wno-incompatible-pointer-types -version -o regrename.s
>>>>> -mexplicit-relocs=always -fdump-rtl-all-all
>>>> I've seen some "guality" test failures in GCC test suite as well.
>>>> Normally I just ignore the guality failures but this time they look 
>>>> very
>>>> suspicious.  I'll investigate these issues...
>>>>
>>> I've also seen this type of failed regression tests and I'll 
>>> continue to
>>> look at this issue as well.
>> The guality regression is simple: I didn't call
>> delegitimize_mem_from_attrs (the default TARGET_DELEGITIMIZE_ADDRESS) in
>> the custom implementation.
>>
>> The failure of this test case was because the compiler believes that two
>> (UNSPEC_PCREL_64_PART2 [(symbol)]) instances would always produce the
>> same result, but this isn't true because the result depends on PC.  Thus
>> (pc) needed to be included in the RTX, like:
>>
>>    [(set (match_operand:DI 0 "register_operand" "=r")
>>      (unspec:DI [(match_operand:DI 2 "") (pc)] 
>> UNSPEC_LA_PCREL_64_PART1))
>>     (set (match_operand:DI 1 "register_operand" "=r")
>>      (unspec:DI [(match_dup 2) (pc)] UNSPEC_LA_PCREL_64_PART2))]
>>
>> With this the buggy REG_UNUSED notes were gone.  But it then prevented
>> the CSE when loading the address of __tls_get_addr (i.e. if we address
>> 10 TLE_LD symbols in a function it would emit 10 instances of "la.global
>> __tls_get_addr") so I added an REG_EQUAL note for it.  For symbols other
>> than __tls_get_addr such notes are added automatically by optimization
>> passes.
>>
>> Updated patch attached.
>>
> I'm eliminating redundant la.global directives in my macro 
> implementation.
>
> I will be testing this patch.
>
>
>
>
With this patch, spec2006 can pass the test, but spec2017 621 and 654 
tests fail.
I haven't debugged the specific cause of the problem yet.