[英雄帖] Upstream LA32R support

[xen0n]

In a private conversation 1.5 years ago, I've asked someone from Loongson about this, but they basically said "no, we won't upstream, let the users use the product version instead" (i.e. support behind paywall). At that time I kinda agreed to not push things forward for a while, because I don't want to deal any (theoretical) "financial damage" to them.

After 1.5 years things haven't changed, but apparently 3rd-party implementations and university projects started to pop up; lack of upstream support is more and more becoming a problem. Everyone has to rely on out-of-tree toolchains (albeit free and libre) which is not going to promote collaboration. At this point, I think pushing LA32R support upstream would be beneficial to the larger LoongArch ecosystem as a whole.

At least the following components need to gain awareness of the new subset:

• [ ] Binutils
• [ ] GCC codegen
  • [ ] calling convention
  • [ ] -march=la32r
• [ ] LLVM IAS / codegen

For now we don't want to care about libc support, because that would force us to decide on a stable LA32 kernel UAPI, that we don't want to. The calling convention is in effect stable enough though -- while GCC can't generate LA32 code, LLVM already can (actually from day 1).

People willing to take up some of this: please reply in the thread to get in touch.

[xry111]

We need new reloc type(s): LA32R only has pcaddu12i, no pcalau12i (unless we live with the stupid stack-based reloc types...)

[xry111]

IMO for ILP32 we should just use the same caller-saved and callee-saved register sets as LP64 (is there any reason not to do this?).

Currently different projects have different (unused yet) stack alignment setting for ILP32: some has 8 bytes and the others have 16 bytes. We need to make the decision.

[xry111]

And can we prove/disprove the conjecture "any LA32R user-space program will have the same behavior on LA64 when CSR.MISC.VA32L3 = 1"? If we disprove it I'd like to distinguish -march=la32r-compatible-with-la64 and -march=la32r-incompatible-with-la64 (with better names).

[jiegec]

Previous attempt: https://patchwork.sourceware.org/project/gcc/list/?series=23251

[xry111]

• [ ] ABI:
  • [ ] Add reloc types: R_LARCH_PCADD, R_LARCH_GOT_PCADD, R_LARCH_TLS_IE_PCADD, R_LARCH_TLS_LD_PCADD,R_LARCH_TLS_GD_PCADD, R_LARCH_TLS_DESC_PCADD
  • They work on adjacent insn pairs, i.e. no HI20/LO12 suffixes.
  • [ ] Add "on 64-bit capable hardware, a ILP32 ABI function expects the arguments passed via a0-a7 sign-extended from 32-bit to 64-bit, and guarantees the return values in a0-a1 sign-extended from 32-bit to 64-bit," and "on 64-bit capable hardware, after an ILP32 function returns, the saved registers s0-s9 can contain either the original value before the function call, or a 64-bit value sign extended from the lower 32-bit of the original value."
  • I cannot see any reasonably way to support running ILP32 programs on LA64 without these requirements. Note that if an ILP32 program isn't intended to run on LA64 at all, it can ignore them.
• [ ] Binutils:
  • [ ] Implement the new reloc types
  • [ ] Complete and enable the existing code for ELFCLASS32
• [ ] GCC and Clang:
  • [ ] -march=la32r
  • Analysis if we need -march=la32r-{in,}compatible-with-la64
  • [ ] -mabi=ilp32s (just focus on s for now, postpone f/d)
• [ ] Kernel and libc (well, we must make them working for testing)
  • Linux and Glibc: non-upstream fork?
  • Make Glibc struct stat and kernel struct statx layout-compatible as Linus suggested for all future 32-bit ports
  • Other kernel/libc???
  • [ ] 64-bit kernel: Allow running ilp32s userspace program with CSR.MISC.VA32L3
  • [ ] 32-bit kernel
• [ ] Hardware
  • Are we legally allowed to make a third-party LA32R implementation???

[xen0n]

On an unrelated note: the CSR.MISC.VA32L* toggles could be used to implement something similar to the novel RV64ILP32 ABI in RISC-V landscape (like MIPS n32 or x86 x32, but without new kernel UAPI -- only the user-space addresses are 32-bit, kernel UAPI stays 64-bit).

[xry111]

It looks like all LA32R user-space program should just run fine on LA64:

1. Output (including accessed mem addr) is always sign-extended or no output at all
  - 1': Require CSR.MISC.VA32L3 enabled
2. Output is sign-extended when the input(s) is/are (all) sign-extended

add.w       1
sub.w       1
addi.w      1
lu12i.w     1
slt[u]      1
slt[u]i     1
pcaddu12i   1'
(all bitwise)   2
mul.w       1
mulh.w[u]   1
div.w[u]    2, notorious LA464 flaw
mod.w[u]    2, notorious LA464 flaw
(all shifts).w  1
(all jumps) 1', PC not really sign extended (if strictly explaining the spec)
        but with VA32L3 it's value is sign extended fetching instructions
[f]ld/st    1', need kABI if an exception triggered
preld       1'
ll.w/sc.w   1', need kABI if an exception triggered
dbar        1
ibar        1
syscall     need kABI
break       need kABI
rdcntvl.w   1, alias of rdtimel.w rd, zero
rdcntvh.w   1, alias of rdtimel.h rd, zero
rdcntid     alias of rdtimel.w zero, rj
        The LA64 manual has unspecified if rj is sign extended
        but it's unlikely someone will make a negative counter ID
        or a counter ID >= 2147483648.
        And the compiler will not use this insn anyway.
movfr2gr.s  1
movfrh2gr.s 1
movcf2gr    1

So we don't need -march=la32r-compatible-with-la64, it's just compatible.