在 2024/1/24 上午3:36, Xi Ruoyao 写道:
On Mon, 2024-01-22 at 15:27 +0800, chenglulu wrote:
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.
Try removing the TARGET_DELEGITIMIZE_ADDRESS hook? After eating some
<del>unhealthy</del> food in the midnight I realized the hook only
papers over the same issue caused spec2006 failure. I tried a bootstrap
with BOOT_CFLAGS=-O2 -g -mcmodel=extreme and TARGET_DELEGITIMIZE_ADDRESS
commented out, and there is no more spurious "note: non-delegitimized
UNSPEC UNSPEC_LA_PCREL_64_PART1 (42) found in variable location" things.
I feel that this hook is still written in a buggy way, so maybe removing
it will solve the spec2017 issue.
I found the problem. Binutils did not consider the four instructions
when converting
the type from TLS IE to TLS LE, which caused the conversion error.
