The Windows x86 EH implementation does not support dynamic stack allocation.
Diff Detail
Unit Tests
Time | Test | |
---|---|---|
60,070 ms | x64 debian > MLIR.Examples/standalone::test.toy | |
60,040 ms | x64 debian > libFuzzer.libFuzzer::minimize_crash.test |
Event Timeline
Hoisting like this is completely unsafe; dynamic allocation is dynamic for a reason (because the allocation is variable size, or happens in a loop).
How do you end up with IR that looks like "@hoist"? clang shouldn't generate IR like that.
How do you end up with IR that looks like "@hoist"? clang shouldn't generate IR like that.
You're right, this IR won't come out of clang --- it's an artifact of a function shrinkwrapping project that someone was working on. The IR seems generically "legal" but was causing a crash later in codegen. The patch avoids the crash.
I just realized that this patch won't address the github issue linked above (60914) because it only hoists catchpad operands. Maybe a more generic solution in WinEH codegen is needed.
If the EH encoding requires that the catchpad point specifically at a static alloca, we should just consider that an invariant, and print a fatal error. I'm not completely sure it's an invariant, since I haven't looked at this part of Windows EH in a while, but that's the impression I get looking at D145286. Ideally the verifier should enforce it, but I'm not sure what the complete rules look like.
(I wouldn't recommend implementing shrink-wrapping by moving around allocas; you probably want something more along the lines of lifetime intrinsics. Maybe consider posting your design on Discourse for feedback.)
I just realized that this patch won't address the github issue linked above (60914) because it only hoists catchpad operands. Maybe a more generic solution in WinEH codegen is needed.
There's clearly a backend bug if dynamic allocation anywhere in the function breaks exception handling. MSVC manages to encode this somehow. (Maybe something related to the frame pointer.)
Thanks for your comments --- I will close this review, and see if a solution can be made on the codegen side.