This ensures that the Windows unwinder will work at every instruction
boundary, and allows other targets to read and write flags without
setting up a frame pointer.
Details
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
llvm/lib/Target/X86/X86FrameLowering.cpp | ||
---|---|---|
103 | isWin64Prologue(MF) && |
This approach works, too (in addition to D92695) and is simpler (though, should X86FrameLowering::has128ByteRedZone now return false for frame using the intrinsics that aren't wincfi? If so, then modification to that method too will degenerate into D92695).
Consider whether D119382 still has value; if it does, perhaps it should land first and/or this patch made a child of it; otherwise happy to abandon it.
Also, in D92695, I modify llvm/test/CodeGen/X86/x86-64-flags-intrinsics.ll. I'm not sure what's preferred for that test. PTAL
It would be helpful to have in the commit message for this patch that it
Yeah, my understanding of has128ByteRedZone is that it is meant to be a target check: does the target have a redzone by convention? So, I think it makes sense to keep the function-specific compatibility checks at the call site where it is used.
Consider whether D119382 still has value; if it does, perhaps it should land first and/or this patch made a child of it; otherwise happy to abandon it.
Now that I found the existing in tree x86-64-flags-intrinsics test, I think we could skip that new test.
Also, in D92695, I modify llvm/test/CodeGen/X86/x86-64-flags-intrinsics.ll. I'm not sure what's preferred for that test. PTAL
You know I went looking for that, but did not find it... I will update it to have it check win64 and linux codegen, since those behave differently now.
It would be helpful to have in the commit message for this patch that it
Sure.
Is there a test which uses flags.read with an alloca to ensure that we obey the redzone rules?
isWin64Prologue(MF) &&