[all-commits] [llvm/llvm-project] 9fe78d: [FunctionAttrs] Fix nounwind inference for landing...

Nikita Popov via All-commits all-commits at lists.llvm.org
Fri Apr 14 02:46:17 PDT 2023


  Branch: refs/heads/main
  Home:   https://github.com/llvm/llvm-project
  Commit: 9fe78db4cd1c18fc36a2f2bcc849adf2941027ba
      https://github.com/llvm/llvm-project/commit/9fe78db4cd1c18fc36a2f2bcc849adf2941027ba
  Author: Nikita Popov <npopov at redhat.com>
  Date:   2023-04-14 (Fri, 14 Apr 2023)

  Changed paths:
    M llvm/include/llvm/IR/Instruction.h
    M llvm/lib/IR/Instruction.cpp
    M llvm/lib/Transforms/IPO/AttributorAttributes.cpp
    M llvm/lib/Transforms/IPO/FunctionAttrs.cpp
    M llvm/test/Transforms/Attributor/nocapture-1.ll
    M llvm/test/Transforms/FunctionAttrs/nounwind.ll

  Log Message:
  -----------
  [FunctionAttrs] Fix nounwind inference for landingpads

Currently, FunctionAttrs treats landingpads as non-throwing, and
will infer nounwind for functions with landingpads (assuming they
can't unwind in some other way, e.g. via resum). There are two
problems with this:

* Non-cleanup landingpads with catch/filter clauses do not
  necessarily catch all exceptions. Unless there are catch ptr null
  or filter [0 x ptr] zeroinitializer clauses, we should assume
  that we may unwind past this landingpad. This seems like an
  outright bug.
* Cleanup landingpads are skipped during phase one unwinding, so
  we effectively need to support unwinding past them. Marking these
  nounwind is technically correct, but not compatible with how
  unwinding works in reality.

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

Differential Revision: https://reviews.llvm.org/D147694




More information about the All-commits mailing list