This is patch is part of a series to introduce an Alignment type.
See this thread for context: http://lists.llvm.org/pipermail/llvm-dev/2019-July/133851.html
See this patch for the introduction of the type: https://reviews.llvm.org/D64790
Details
Diff Detail
- Repository
- rG LLVM Github Monorepo
- Build Status
Buildable 40259 Build 40359: arc lint + arc unit
Event Timeline
llvm/lib/Target/X86/X86ISelLowering.cpp | ||
---|---|---|
4186–4192 | This is not the same as the previous code for all values: https://godbolt.org/z/QTxj9U | |
22264 | Let's refactor this in Align (in a separate patch). |
llvm/lib/Target/X86/X86ISelLowering.cpp | ||
---|---|---|
4186–4192 | I traced the addition of this code back to rL42870 (2007). Since the author is probably not working on this any more I'm redirecting to @craig.topper (from CODE_OWNERS.TXT). The original code can be rewritten as: unsigned GetAlignedArgumentStackSize(uint64_t StackSize, uint64_t StackAlignment, uint64_t SlotSize) { const uint64_t AlignMask = StackAlignment - 1; const uint64_t lowBits = StackSize & AlignMask; const uint64_t hiBits = StackSize & ~AlignMask; if (lowBits <= (StackAlignment - SlotSize)) return StackSize - lowBits + StackAlignment - SlotSize; return StackAlignment + hiBits + StackAlignment - SlotSize; } I believe the last line is wrong, at least I can't wrap my head around it. As such I believe the patch cannot be NFC anymore. | |
22264 | SGTM |
Not previously, but from looking at it, I'd say the simplification is fine. This code is only called from the guaranteed TCO codepath, so I'm not surprised it's lightly tested.
llvm/lib/Target/X86/X86ISelLowering.cpp | ||
---|---|---|
4186–4192 | I think the code only differs when StackAlignment is less than SlotSize, which should never happen in practice. I suspect we rely on that invariant in other places. I edited the godbolt program to avoid such test cases and now the algorithms always produce the same values: https://godbolt.org/z/MqPErL And, the only way to exercise the second case in the original code would be if StackSize is not a multiple of SlotSize, which seems unlikely. I suspect we align StackSize to SlotSize somewhere else. If you wanted to add test coverage for this case, I'd experiment with multiple one byte allocas. In the end, I think it's safe to take your simplification. |
This is not the same as the previous code for all values: https://godbolt.org/z/QTxj9U
Could you at least add an assert if you don;t intend to cover the same range of inputs ?