In D105866, we used an intermediate container to store a list of opcodes. Here,
we use that data structure to help us perform optimization passes that would allow
a more efficient encoding of bind opcodes. Currently, the functionality mirrors the
optimization pass {1,2} done in ld64 for bind opcodes under optimization gate
to prevent slight regressions.
Details
- Reviewers
int3 gkm - Group Reviewers
Restricted Project - Commits
- rGd695d0d6f605: [lld-macho] Optimize bind opcodes with multiple passes
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
There is twice a 15 in your code. Are these magic numbers or could they be named constants?
15 is the limit for data to be compacted within a single byte; otherwise it needs to be expanded. It turns out there is already a constant BIND_IMMEDIATE_MASK that already defines these values. I plan to separate pass 3 in a separate diff since that might involve some more changes.
Really stupid question: Are you tied to the order of entries in the vector or could changing the order allow further optimizations?
@tschuett we already sort the bindings (in sortBindings) so the order should be pretty amenable to optimization
lld/MachO/Driver.cpp | ||
---|---|---|
1173 | LLD-ELF defaults this to 1; I think we should follow suit (and gate the bind opcode optimization to > 1) | |
lld/MachO/SyntheticSections.cpp | ||
375–377 | nit: LLVM convention is to omit braces for one-liners | |
lld/test/MachO/lit.local.cfg | ||
19 ↗ | (On Diff #358841) | The -O flag should be in the bind-opcodes.s test file, instead of being turned on for all tests |
Will fix the rest.
lld/MachO/Driver.cpp | ||
---|---|---|
1173 | I was considering that, but when I looked at the definitions of how clang (https://clang.llvm.org/docs/CommandGuide/clang.html#cmdoption-o0) uses the -O flag, they define -O0 as no optimizations which seemed fitting since we don't do any of it right now. That said, this does deviate from the LLD-ELF conventions and I'm happy to take either approaches if you feel strongly that it should be 1. |
lld/MachO/Driver.cpp | ||
---|---|---|
1173 | yeah I think we should follow LLD-ELF more closely than we follow clang |
LLD-ELF defaults this to 1; I think we should follow suit (and gate the bind opcode optimization to > 1)