[all-commits] [llvm/llvm-project] b3cb4f: [StackColoring] Handle SEH catch object stack slot...

[Nikita Popov via All-commits]

  Branch: refs/heads/main
  Home:   https://github.com/llvm/llvm-project
  Commit: b3cb4f069c2cb99bdae68d6906156af20e76314f
      https://github.com/llvm/llvm-project/commit/b3cb4f069c2cb99bdae68d6906156af20e76314f
  Author: Nikita Popov <npopov at redhat.com>
  Date:   2023-09-22 (Fri, 22 Sep 2023)

  Changed paths:
    M llvm/lib/CodeGen/StackColoring.cpp
    R llvm/test/CodeGen/X86/stack-coloring-seh.ll
    A llvm/test/CodeGen/X86/stack-coloring-wineh.ll

  Log Message:
  -----------
  [StackColoring] Handle SEH catch object stack slots conservatively

The write to the SEH catch object happens before cleanuppads are
executed, while the first reference to the object will typically
be in a catchpad.

If we make use of first-use analysis, we may end up allocating
an alloca used inside the cleanuppad and the catch object at the
same stack offset, which would be incorrect.

https://reviews.llvm.org/D86673 was a previous attempt to fix it.
It used the heuristic "a slot loaded in a WinEH pad and never
written" to detect catch objects. However, because it checks
for more than one load (while probably more than zero was
intended), the fix does not actually work.

The general approach also seems dubious to me, so this patch
reverts that change entirely, and instead marks all catch object
slots as conservative (i.e. excluded from first-use analysis)
based on the WinEHFuncInfo. As far as I can tell we don't need
any heuristics here, we know exactly which slots are affected.

Fixes https://github.com/llvm/llvm-project/issues/66984.