This hint instructs the linker to perform the AdrpLdr or AdrpAdd
transformation depending on whether the GOT load has been relaxed to
load a local symbol's address directly.
Details
- Reviewers
thakis - Group Reviewers
Restricted Project - Commits
- rG2028fe6fbca6: [lld-macho] Handle LOH_ARM64_ADRP_LDR_GOT optimization hints
Diff Detail
Event Timeline
\o/
lld/MachO/Arch/ARM64.cpp | ||
---|---|---|
223 | ld64's version of this is called parseLoadOrStore and it finds stores too. will we do that later, or will we never relax stores? | |
405 | I suppose these are rare enough that calling parseLdr() once before this function and then once again in this function isn't a big deal? | |
418 | ld64 doesn't do this check for LOH_ARM64_ADRP_LDR_GOT afaict (?) |
lld/MachO/Arch/ARM64.cpp | ||
---|---|---|
223 | ld64 has a handy -verbose_optimization_hints flag, these are the stats for the usual Chromium Framework repro file: ❯ ld @response.txt -verbose_optimization_hints 2>&1 | grep 'transformed to' | cut -d ' ' -f1 | sort | uniq -c | sort -n 24 adrp-add-str 319 adrp-add-ldr 341 adrp-ldr-got-str 4056 adrp-ldr-got 115745 adrp-add 121578 adrp-ldr-got-ldr Based on this, store LOHs are quite rare, so I opted for making this function more compact and readable instead. But if we get around to adding the two store hints, a separate parseStr parser function would be better for readability. | |
405 | I'm likely going to have to split checking + the actual relaxation into helper functions for the ADRP_LDR_GOT_LDR feature, is it okay if I remove the redundant check in that commit? | |
418 | ld64 asserts in makeLDR_literal that the load's size is 4, 8 or 16 bytes though, |
lld/MachO/Arch/ARM64.cpp | ||
---|---|---|
405 | Sure, sounds good :) |
ld64's version of this is called parseLoadOrStore and it finds stores too. will we do that later, or will we never relax stores?