In small code model, program and its symbols are linked in the lower 2 GB of the address space. Try encoding global symbol address even when the range is unknown in such case.
Details
Diff Detail
- Repository
- rG LLVM Github Monorepo
Unit Tests
Time | Test | |
---|---|---|
650 ms | linux > HWAddressSanitizer-x86_64.TestCases::sizes.cpp |
Event Timeline
Is this something we can detect in X86DAGToDAGISel::isSExtAbsoluteSymbolRef? We already have a pattern for X86sub_flag that calls that. Same for a bunch of other instructions.
Would be good to share benchmark/performance numbers you have for this change too. Thanks.
Thanks for the comment, Craig.
isSExtAbsoluteSymbolRef does seem to check for the width of immediate. If the immediate can be encoded directly, the node should be replaced with one of the SUB64ri* nodes. I think the X86Wrapper node can be replaced with a corresponding imm node if conditions are met, then the matching can proceed.
Sure. This change is to address some codegen difference we saw between clang and gcc from internal workloads. Gcc seems to prefer encoding address immediate into cmp in small code model. With the change, we saw 1% perf improvement on average across multiple workloads.
I was thinking that if we don't have range information from getAbsoluteSymbolRange, but the Width passed to isSExtAbsoluteSymbolRef is 32 and the code model is small we could return true?
Yes, I think it is possible to do that. The similar check is also done in X86DAGToDAGISel::selectMOV64Imm32.
Sorry for the long delay. Got held up by some other task.
Update:
- modified change as suggested.
- fixed several test cases due to the change.
- added a new test case.
clang-format: please reformat the code