[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