On Thu, 2024-01-25 at 08:48 +0800, chenglulu wrote: > > 在 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.
Oooops. We better fix this quickly as the Binutils 2.42 release is imminent. Maybe we can just disable TLS linker optimization once we see an R_LARCH_TLS_DESC64* or R_LARCH_TLS_IE64*. -- Xi Ruoyao <xry...@xry111.site> School of Aerospace Science and Technology, Xidian University
