[all-commits] [llvm/llvm-project] ad6b57: SCCP: Don't assert on constantexpr casts of functi...
Matt Arsenault via All-commits
all-commits at lists.llvm.org
Thu Dec 22 14:05:37 PST 2022
Branch: refs/heads/main
Home: https://github.com/llvm/llvm-project
Commit: ad6b5762b64f6706cb4d1bcad383c373736b5af6
https://github.com/llvm/llvm-project/commit/ad6b5762b64f6706cb4d1bcad383c373736b5af6
Author: Matt Arsenault <Matthew.Arsenault at amd.com>
Date: 2022-12-22 (Thu, 22 Dec 2022)
Changed paths:
M llvm/lib/Transforms/IPO/SCCP.cpp
A llvm/test/Transforms/SCCP/issue59602-assume-like-call-users.ll
Log Message:
-----------
SCCP: Don't assert on constantexpr casts of function uses
This includes 2 different, related fixes:
1. Fix asserting on direct assume-like intrinsic uses of a function
address
2. Fix asserting on constant expression casts used by assume-like
intrinsics.
By default hasAddressTaken permits assume-like intrinsic uses, which
ignores assume-like calls and pointer casts of the address used by
assume-like calls.
Fixes #59602, but there are additional issues I encountered when
debugging this. For instance, the original failing bitcast expression
was really unused. Clang tentatively created it for the function type,
but was unnecessary after applyGlobalValReplacements. That did not
clean up the now dead ConstantExpr which hung around oun the user
list, so this assert only reproduced when running clang from the
original testcase, and didn't just running opt -passes=ipsccp. I don't
know who is responsible for cleaning up unused ConstantExprs, but I've
run into similar issues several times recently.
Additionally, I found a few assertions with llvm.ssa.copy with
functions and casts of functions as the argument.
Another issue theoretically exists if hasAddressTaken chooses to
respect nocapture when passed function addresses. The search here
would need to do additional work to look at the users of the constant
cast to see if any call sites need returned to be stripped.
More information about the All-commits
mailing list