Prioritize addresses relative to the stack pointer in the stackmap, but fallback gracefully to other modes of addressing if the offset to the stack pointer is not a known constant.
Details
Diff Detail
Event Timeline
Hi,
I'm happy to review these (and thanks for the patches!) but can you please split these up into three patches?
include/llvm/Target/TargetFrameLowering.h | ||
---|---|---|
255–257 | Why not return an Optional<int>? |
- split out the two small fixes at http://reviews.llvm.org/D21287 and http://reviews.llvm.org/D21286
- use optional type
include/llvm/Target/TargetFrameLowering.h | ||
---|---|---|
260 | Just return None; | |
lib/CodeGen/AsmPrinter/WinException.cpp | ||
305 | No need to use braces here. Also, this indent looks weird -- is it clang-formatted? Note: you can also use *TFI.getFrameIndexReferenceFromSP(*Asm->MF, FrameIndex, UnusedReg) instead of getValue. | |
lib/CodeGen/PrologEpilogInserter.cpp | ||
1102 | I'd suggest pushing the hasReservedCallFrame check into getFrameIndexReferenceFromSP -- getFrameIndexReferenceFromSP be returning None or a valid offset. | |
1105 | Note: instead of if (X.hasValue()) you can also do if (X). Since Optional<T> does not auto-convert to T (you need to use its operator* or getValue()) there are no messy cases around e.g. an Optional<int> containing 0 as its value looking like it has no value etc. | |
lib/Target/X86/X86FrameLowering.cpp | ||
1765 | Use return None; and remove the braces. | |
1810 | You don't need to explicitly create an Optional<int>, you can just return Offset + StackSize. | |
test/CodeGen/X86/statepoint-nosp.ll | ||
3 | You'll need a REQUIRES: asserts here otherwise the test will fail on product builds that don't have -debug-only. |
Btw, here are our coding standards, in case that helps: http://llvm.org/docs/CodingStandards.html
re: putting the hasReservedCallFrame check
I don't think it's possible since the other use site of this function (in WinException) seem to actually use it in that case. I'm assuming that in this context it's guaranteed that the offset will only be interpreted relative to the stack pointer on function entry.
I've added a comment to reflect that at the getFrameIndexReferenceFromSP declaration.
@rnk -- can you confirm if the above is intentional? If it is, then lgtm else lets move hasReservedCallFrame into getFrameIndexReferenceFromSP.
include/llvm/Target/TargetFrameLowering.h | ||
---|---|---|
252 | I'd change the language a little bit to say ".. except that the 'base register' will always be RSP and the offset is from the value of RSP after the function prologue" |
WinEH does not expect getFrameIndexReferenceFromSP to return a result which is dynamically correct from an arbitrary program point.
The result of getFrameIndexReferenceFromSP goes into data, not code. The idea is that the exception handling runtime wants to know the offset of the exception object relative to what the SP is after the prologue is set up.
The runtime uses CFI to recreate the stack pointer at prologue start; that, coupled with the offset, is utilized to initialize stuff like catch objects.
Given what @majnemer said, do you mind adding a boolean to the getFrameIndexReferenceFromSP API as bool AllowSPAdjustment with the semantic that if it is true then the offset returned is correct only based off of the SP on entry, while if it is false then the offset (if any returned) has to be correct for the SP at arbitrary program points after the prologue? Currently the API is such that other than documentation there is nothing that will force a user to carefully think about which variant they want.
Is it really necessary to prefer SP-relative offsets from FP-relative offsets? Is there any reason not to standardize on getFrameIndexReference? You can always get SP-relative offsets by disabling frame pointers.
Assuming we need SP-relative offsets, I think it would be cleaner to expose an API on TargetFrameLowering that prefers returning SP-relative offsets if possible, rather than having an API that might fail. The base TargetFrameLowering implementation can delegate directly to getFrameIndexReference, and targets like X86 can implement the preference for SP-relative offsets.
We do want to prefer SP relative offsets, even when we're preserving frame pointers. But I like your second idea, I'll put up a patch for review soon.
I'd change the language a little bit to say ".. except that the 'base register' will always be RSP and the offset is from the value of RSP after the function prologue"