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.

[Xi Ruoyao <xry111@xry111.site>]

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