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. -- Xi Ruoyao <xry...@xry111.site> School of Aerospace Science and Technology, Xidian University
