[llvm] [RISCV] Xqcilb: remove RISCVMCExpr::VK_QC_E_JUMP_PLT and drop `@plt` parsing (PR #135507)

[Fangrui Song via llvm-commits]

MaskRay wrote:

> It looks like we're going to keep disagreeing about whether the `@plt` is useful or misleading, but if there are weird parsing artefacts when there's an offset, then I'm happy to drop support for it for Xqcilb.

Ah, that's just how it goes. My primary concern is the overuse of `@` than the actual relocation type name...

> I will update my docs to reflect that the `@plt` is not needed.

Thanks! Is there a doc about the instruction encoding? Searching RISC-V Xqcilb online doesn't give me much information. The most relevant one is https://github.com/quic/riscv-elf-psabi-quic-extensions , the psABI extension, not an ISA manual.

> I think the fixup should not be renamed. It is aligned with the relocation name, and I think the correspondence is useful and valid. I haven't seen a clear reason to rename the relocation from this discussion, and continue to find the fact the relocation ends in `_PLT` to be useful.

Restored the fixup name.

Personally I'd lean towards `_CALL` instead of `_JUMP` for a relocation with procedure call semantics.
But it's your extension, so ultimately, it's your call:)

(The infix "JUMP"  does not convey clear meaning in AArch32: some short-range R_ARM_THM_JUMP* relocations lack range extension thunks/veneers, while R_ARM_THM_JUMP24 does have them.)

> I think that we no longer need `PseudoQCJumpSymbol`, `pseudo_qc_jump_symbol`, `PseudoQC_E_J`, and `PseudoQC_E_JAL`, all of which were just for the custom symbol parsing. If we accept a bare symbol, I think we just update `simm32_lsb0` to instead be `bare_simm32_lsb0` in `QCIRVInst48EJ`, and have it accept bare symbols.

Thanks for the guide! It's been helpful in getting me reacquainted with those TableGen AsmParser methods. I think I understand it now.


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