[ABI] Default to the medium code model across the board

[xen0n]

Large apps, such as Chromium, and potentially in-house services that are written in C++ and/or Rust and featuring huge polymorphic business logic, are going to have text sections larger than 256MiB, that the current default code model of normal cannot handle.

We could ask such devs to manually add -mcmodel=medium or even extreme to their projects, but the problem is: users rarely are aware of their own software's growth, and arguably they shouldn't care, and (IMO) it's definitely not the users' fault if their project suddenly fails to link just because one more feature is added that pushed the text section size over the tipping point.

Instead, I'd like to propose that we allow and implement the relaxation of call36 to bl, then effectively merge the normal and medium code models:

• either make normal an alias of medium,
• or switch the defaults to medium for popular toolchain projects,
• or both.

This way, small programs' performance should stay the same thanks to relaxation, and larger programs should get transparently supported. And all of this without any user intervention. The 256GiB 4GiB text section and 4GiB data access range allowed by the medium code model should be enough for the foreseeable future; the extreme code model should be required only for advanced use cases and/or supercomputing.

Progress

• Rust: since 1.83.0
  • target: default to the medium code model on LoongArch targets rust-lang/rust#120661
  • target: default to the medium code model on LoongArch targets rust-lang/rust#130266
  • Default to the medium code model on OpenHarmony LoongArch target rust-lang/rust#131874
• LLVM: since 21
  • llvm/llvm-project@2d876ed
• GCC: since 16
  • gcc-mirror/gcc@cc3ade6
• Go: expected for 1.26.0
  • https://go.dev/cl/709717

[xry111]

The 256GiB text section and 4GiB data access range allowed by the medium code model should be enough for the foreseeable future

Still 4GiB text section because when you take a function pointer it's still pcalau12i + addi.d. My mistake writing the NEWS for Binutils.

[xen0n]

The 256GiB text section and 4GiB data access range allowed by the medium code model should be enough for the foreseeable future

Still 4GiB text section because when you take a function pointer it's still pcalau12i + addi.d. My mistake writing the NEWS for Binutils.

Oh heck, asymmetry. (And it's not your fault because that sentence is most likely written by me and you merely took my suggestion...)

[xen0n]

Alternatively we could also implement range extension thunks for LoongArch, that should hopefully allow linking of existing object code. This is orthogonal to the medium code model support though.

[alexrp]

I wasn't aware of this repository until now, so I posted an RFC related to this on the LLVM Discourse: https://discourse.llvm.org/t/rfc-changing-the-default-code-model-for-loongarch/85317

[xry111]

Considering the conservative nature of the relaxation algorithm, I'm concerned that relaxation may not be able to cancel out all the negative impacts of -mcmodel=medium. Is there some results from real-life software projects (like Glibc)?

[alexrp]

Is there some results from real-life software projects (like Glibc)?

I don't have any personally.

However, I would argue that the performance impact ought not be a significant factor here. The problems with the current default are very real and will only become more problematic with time. Similarly, it'll only become more painful to change the default with time. I think we should just bite the bullet and hope that subsequent work on linker relaxation can close the performance gap.

At the end of the day, performance gained based on a default that is problematic for the whole software ecosystem is rather questionable to begin with.

[alexrp]

llvm/llvm-project#132173

[xen0n]

Go's internal linker has gained loong64 support since Go 1.25, and it needs to get R_LARCH_CALL36 support very soon. Linking errors are already seen in the wild.