[lld] ELF,SystemZ: Don't sort relocations for TLS GD/LD optimization; support CREL (PR #149640)

[Fangrui Song via llvm-commits]

MaskRay wrote:

> > CREL does not support random access. To allow the GDCALL/PLT32, we would need to decode them to RELA and sort them first...
> 
> Ah, I see. But it should be possible to "peek" at the next relocation, right? So we might add something to the main `scanOne` loop to the effect of: if _this_ reloc is a `R_390_PLT32DBL` _and_ the _next_ reloc is a `R_390_TLS_GDCALL` or `R_390_TLS_LDCALL` which we know we'll able to optimize, then simply ignore this (`R_390_PLT32DBL`) reloc?

In `RelocationScanner::scanOne`, the parameter `typename Relocs<RelTy>::const_iterator &i` can be changed to support MIPS. It pessimized generic code... I don't want more targets to skip relocations like that or do EM_PPC64 checks for `.toc` and IBM XL/C TLS workarounds.  In the long term scanOne should become a template instantiated by targets, so that these target workarounds do not affect performance of other targets. mold adopts this approach.

I plan not to do anything with with GDCALL/PLT32 skipping because it is a minor thing and GNU ld doesn't skip PLT32DBL...

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