[MC] Don't pass MCSubtargetInfo down to shouldForceRelocation and evaluateTargetFixup by MaskRay · Pull Request #141311 · llvm/llvm-project (original) (raw)
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.Learn more about bidirectional Unicode characters
[ Show hidden characters]({{ revealButtonHref }})
…luateTargetFixup
This reverts the code change in commit e87f33d (llvm#73721) but keeps its test.
llvm#73721, a workaround to generate necessary relocations in mixed non-relax/relax code, is no longer necessary after llvm#140692 fixed the root issue (whether two locations are separated by a fragment with indeterminate size due to linker relaxation).
MaskRay added a commit that referenced this pull request
After #141311 removed the MCSubtargetInfo argument from shouldForceRelocation, addReloc does not need this argument, either.
In a rare scenario that the information is needed, the target should check the MCFragment subclass and get it from MCDataFragment/MCRelaxableFragment.
MaskRay added a commit that referenced this pull request
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.