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
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 ?