[llvm] [LoongArch] Support R_LARCH_{ADD, SUB}_ULEB128 for .uleb128 and force relocs when sym is not in section (PR #76433)

[Fangrui Song via llvm-commits]

MaskRay wrote:

> > Ah, it's only explaining that zero-padding should be done on LoongArch. But I'm not sure if @MaskRay was asking for the reason behind the difference, i.e. the design considerations behind the decision.
> 
> I just followed psABI in this pr. My idea is that {ADD,SUB}_ULEB128 follows the other ADD and SUB relocation types. There is no order between ADD and SUB, while SET needs to be executed before SUB. However, in the object file, the initial value is more helpful for debug information to print, otherwise we need to relocate and fix them. For example the resolveLoongArch fixes ADD and SUB to display the debug information of object file normally. Both of them has its own advantages I think.

My recollection from the RISC-V side discussion: SET_ULEB128/SUB_ULEB128 should be used consecutively and other forms (e.g. SET_ULEB128 without a SUB_ULEB128).
A `.uleb128 directive` is wasteful when used without SUB_ULEB128 (10 bytes for an unconstrained uint64_t) and there isn't a use case for it.

I wonder whether LoongArch can rename `R_LARCH_ADD_ULEB128` to `R_LARCH_SET_ULEB128` and define the symbol `R_LARCH_ADD_ULEB128` as an alias if compatibility is needed.
If GNU assembler ensures that `.uleb128 A-B` creates a zero padding, there is no functional difference switching to the SET semantics.
Assemblers and linkers can enjoy simplification from having `R_LARCH_SET_ULEB128` defined the same as `R_RISCV_SET_ULEB128`.


https://github.com/llvm/llvm-project/pull/76433