Follow-up to #141333. Relocation generation called both addReloc and applyFixup, with the default addReloc invoking shouldForceRelocation, resulting in three virtual calls. This approach was also inflexible, as targets needing additional data required extending `shouldForceRelocation` (see #73721, resolved by #141311). This change integrates relocation handling into applyFixup, eliminating two virtual calls. The prior default addReloc is renamed to maybeAddReloc. Targets overriding addReloc now call their customized addReloc implementation.
It is only required by ARM, which can now use the member variable.
Remove the MCSubtargetInfo argument from applyFixup, introduced in https://reviews.llvm.org/D45962 , as it's only required by ARM. Instead, add const MCFragment & so that ARMAsmBackend can retrieve MCSubtargetInfo via a static member function. Additionally, remove the MCAssembler argument, which is also only required by ARM. Additionally, make applyReloc non-const. Its arguments now fully cover addReloc's functionality.
A lot of member functions have the MCAssembler * argument just to call getContext. Let's cache the MCAssembler pointer.
This reverts the code change in commit e87f33d9ce785668223c3bcc4e06956985cccda1 (#73721) but keeps its test. There have been many changes to lib/MC and AsmBackend.cpp files, so this is not a pure revert. #73721, a workaround to generate necessary relocations in mixed non-relax/relax code, is no longer necessary after #140692 fixed the root issue (whether two locations are separated by a fragment with indeterminate size due to linker relaxation).
For IsPCRel fixups, we had the `A->getKind() != MCSymbolRefExpr::VK_None` condition to force relocations. The condition has then been changed to `Target.getSpecifier()` (086af836889436baffc71c743c7c8259bad8ed60). 38c3ad36be1facbe6db2dede7e93c0f12fb4e1dc updated shouldForceRelocation to test `Target.getSpecifier`. It is not a good fit as many targets with %lo/%hi style specifiers (SPARC, MIPS, PowerPC, RISC-V) do not force relocations for these specifiers. Revert the Target.getSpecifier implementation (38c3ad36be1facbe6db2dede7e93c0f12fb4e1dc) and update targets that need it (SystemZAsmBackend/X86AsmBackend) instead. Targets need customization might define addReloc instead. Note: The X86AsmBackend implementation is too conservative. GNU Assembler doesn't emit a relocation for `call local@plt; local` a3d39316764726ed9fd939550c7781199b1eb77e added missing coverage for GOT/PLT related relocations.
This reverts commit 6f6dc1f239433393c0b09430193beb85d03464c8. Resulted in several bot failures.
Revert the Target.getSpecifier implementation (38c3ad36be1facbe6db2dede7e93c0f12fb4e1dc) and update SystemZAsmBackend instead. Many targets with %lo/%hi style specifiers (SPARC, MIPS, PowerPC, RISC-V) do not force relocations for these specifiers. Additionally, with the introduction of the addReloc hook, shouldForceRelocation is not that necessary and should probably be phased out.
We will increase the use of raw relocation types and eliminate fixup kinds that correspond to relocation types. The getFixupKindInfo functions will return an rvalue instead. Let's update the return type from a const reference to a value type.