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

Sat Mar 4 16:24:25 PST 2023

efriedma added a comment.

In D145275#4168967 <https://reviews.llvm.org/D145275#4168967>, @clin1 wrote:

> 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 <https://reviews.llvm.org/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.)

Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D145275/new/

https://reviews.llvm.org/D145275