This attribute is used to ensure the guard page is triggered on stack overflow. Stack frames larger than the guard page size will generate a call to __probestack to touch each page so the guard page won't be skipped.
Details
Diff Detail
Event Timeline
Has this been discussed on LLVMdev? Our development process requires
changes to the IR to have a design discussion on LLVMdev first.
- Sean Silva
This now uses the string attribute "probe-stack". Dynamic allocations will have stack probes added. I also added a fast path for smaller frames.
Used the right scale value on the OR instruction. Change the relocation to the __probestack call on non-Windows x86-64 platforms.
This is originally 4 commits: https://github.com/Zoxc/llvm/compare/llvm-mirror:master...stprobe
lib/Target/X86/X86FrameLowering.cpp | ||
---|---|---|
749 | The original code has 4 space indentation here. Don't blame me. |
Overall, I like the direction of the change, but there's a number of details which need adjusted before it's ready for submission. The biggest is that this patch seems to combine a bunch of separate pieces and it would be better to factor this apart into a series of patches which each do one thing. This would make it much easier to review.
include/llvm/CodeGen/MachineFunction.h | ||
---|---|---|
271 | Could you define the term "probing the stack" here? This is likely be where an LLVM developer might encounter the concept. One short sentence is fine. | |
lib/Target/ARM/ARMFrameLowering.cpp | ||
304 | Seems like you should rename WindowsRequiredStackProbe since this is no longer Windows specific. | |
lib/Target/X86/X86FrameLowering.cpp | ||
500 | What is this magic constant? At minimum, comment it. This looks like it might be an independent bugfix? If so, please submit separately. | |
673 | This section is a large diff that I'm having trouble understanding. If you can split this up into a set of smaller patches, that would help a lot. | |
675–705 | Magic numbers? What do these mean? | |
708–709 | In a separate change, exacting out this code out as a helper function (getStackProbeSymbol(..)) would make the functional diff easier to follow. | |
712 | I don't understand this section at all. What's the motivation here? Again, could this be separate patch? | |
lib/Target/X86/X86ISelLowering.cpp | ||
18214 | This condition "feels" wrong. It looks like you're only avoiding this case for 32 bit Windows? Why? The old code didn't. | |
18249 | I'm not clear on what this change is doing. In addition to the changed symbol, it looks like you're adding 64 vs 32 bit case? Is this an unrelated bugfix? | |
lib/Transforms/IPO/Inliner.cpp | ||
140 | Add a comment to justify. Would it be better to just prevent inlining when only one has probe-stack? (i.e. is this expected to ever happen?) | |
test/CodeGen/X86/mingw-alloca.ll | ||
32 | Why are you modifying the existing test rather than adding a new one? Is this test incorrect? It doesn't seem to be on first read. | |
test/CodeGen/X86/pr17631.ll | ||
21 | This looks like it goes with an optimization? Can you add a test case for the unoptimized case? Again, optimizations should be separate patches. | |
test/CodeGen/X86/stack-probes.ll | ||
2 | Why bother with a custom prefix if they are the same? You can just use the default CHECK prefix. | |
24 | A comment describing what each test is checking for would be helpful. | |
test/CodeGen/X86/win64_alloca_dynalloca.ll | ||
13 | Why are you modify existing tests rather than adding new ones? Is this because of a new optimization? |
A newer version was posted to the mailing list.
lib/Target/X86/X86ISelLowering.cpp | ||
---|---|---|
18214 | The old code did also just avoid 32-bit Windows (the only other case was 64-bit Windows) | |
18249 | This calls the x86-32 probestack function the same way as x86-64 chkstk/__probestack. I'll make this more explicit. | |
test/CodeGen/X86/stack-probes.ll | ||
2 | A custom prefix seems to be the pattern, and it makes sense if tests for other platforms will be added. |
Could you define the term "probing the stack" here? This is likely be where an LLVM developer might encounter the concept. One short sentence is fine.