在 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.
