This is an archive of the discontinued LLVM Phabricator instance.

[CGP] Hoist allocas used in catchpad instructions, if they are not in the entry block.
AbandonedPublic

Authored by clin1 on Mar 3 2023, 2:33 PM.

Details

Reviewers
LuoYuanke
pengfei
Summary

The Windows x86 EH implementation does not support dynamic stack allocation.

Diff Detail

Event Timeline

clin1 created this revision.Mar 3 2023, 2:33 PM
Herald added a project: Restricted Project. · View Herald TranscriptMar 3 2023, 2:33 PM
Herald added a subscriber: hiraditya. · View Herald Transcript
clin1 requested review of this revision.Mar 3 2023, 2:33 PM
Herald added a project: Restricted Project. · View Herald TranscriptMar 3 2023, 2:33 PM

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.

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.

Can we ingore dynamic alloca like https://reviews.llvm.org/D145286?

How do you end up with IR that looks like "@hoist"? clang shouldn't generate IR like that.

clin1 added a comment.Mar 3 2023, 9:42 PM

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.

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.

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.)

clin1 added a comment.Mar 6 2023, 11:34 PM

Thanks for your comments --- I will close this review, and see if a solution can be made on the codegen side.

clin1 abandoned this revision.Mar 6 2023, 11:35 PM