[NFC] Fix use-after-free: track TargetLibraryAnalysis in BasicAAResult invalidation - #183852
Conversation
… invalidation BasicAAResult holds a reference to TargetLibraryInfo but its invalidate() method did not check TargetLibraryAnalysis. When the pass manager destroyed and re-created TLI (e.g. during CGSCC invalidation or FAM.clear()), BasicAAResult survived with a dangling TLI reference because it only tracked AssumptionAnalysis and DominatorTreeAnalysis as dependencies. This was exposed by commit f9f62ef which added aliasErrno(), the first code path that dereferences TLI from BasicAAResult during the CGSCC pipeline, causing a STATUS_ACCESS_VIOLATION crash when compiling rust core on aarch64-pc-windows-msvc. Add TargetLibraryAnalysis to the invalidation check so BasicAAResult is properly invalidated when its TLI reference becomes stale.
|
@llvm/pr-subscribers-llvm-analysis Author: Daniel Paoliello (dpaoliello) Changes
This was exposed by !157495 which added This change adds Full diff: https://github.com/llvm/llvm-project/pull/183852.diff 1 Files Affected:
diff --git a/llvm/lib/Analysis/BasicAliasAnalysis.cpp b/llvm/lib/Analysis/BasicAliasAnalysis.cpp
index 1d5f9ac465808..64e035436a414 100644
--- a/llvm/lib/Analysis/BasicAliasAnalysis.cpp
+++ b/llvm/lib/Analysis/BasicAliasAnalysis.cpp
@@ -86,7 +86,8 @@ bool BasicAAResult::invalidate(Function &Fn, const PreservedAnalyses &PA,
// may be created without handles to some analyses and in that case don't
// depend on them.
if (Inv.invalidate<AssumptionAnalysis>(Fn, PA) ||
- (DT_ && Inv.invalidate<DominatorTreeAnalysis>(Fn, PA)))
+ (DT_ && Inv.invalidate<DominatorTreeAnalysis>(Fn, PA)) ||
+ Inv.invalidate<TargetLibraryAnalysis>(Fn, PA))
return true;
// Otherwise this analysis result remains valid.
|
|
/cherry-pick 7886257 |
|
/pull-request #183865 |
…t invalidation (llvm#183852) `BasicAAResult` holds a reference to `TargetLibraryInfo` but its `invalidate()` function did not check `TargetLibraryAnalysis`. When the pass manager destroyed and re-created `TLI` (e.g. during `CGSCC` invalidation or `FAM.clear()`), `BasicAAResult` survived with a dangling `TLI` reference. This was exposed by llvm#157495 which added `aliasErrno()`, the first code path that dereferences `TLI` from `BasicAAResult` during the `CGSCC` pipeline, causing a AV when compiling Rust's core library on Arm64 Windows. This change adds `TargetLibraryAnalysis` to the invalidation check so `BasicAAResult` is properly invalidated when its `TLI` reference becomes stale.
…t invalidation (llvm#183852) `BasicAAResult` holds a reference to `TargetLibraryInfo` but its `invalidate()` function did not check `TargetLibraryAnalysis`. When the pass manager destroyed and re-created `TLI` (e.g. during `CGSCC` invalidation or `FAM.clear()`), `BasicAAResult` survived with a dangling `TLI` reference. This was exposed by llvm#157495 which added `aliasErrno()`, the first code path that dereferences `TLI` from `BasicAAResult` during the `CGSCC` pipeline, causing a AV when compiling Rust's core library on Arm64 Windows. This change adds `TargetLibraryAnalysis` to the invalidation check so `BasicAAResult` is properly invalidated when its `TLI` reference becomes stale.
…t invalidation (#183852) `BasicAAResult` holds a reference to `TargetLibraryInfo` but its `invalidate()` function did not check `TargetLibraryAnalysis`. When the pass manager destroyed and re-created `TLI` (e.g. during `CGSCC` invalidation or `FAM.clear()`), `BasicAAResult` survived with a dangling `TLI` reference. This was exposed by #157495 which added `aliasErrno()`, the first code path that dereferences `TLI` from `BasicAAResult` during the `CGSCC` pipeline, causing a AV when compiling Rust's core library on Arm64 Windows. This change adds `TargetLibraryAnalysis` to the invalidation check so `BasicAAResult` is properly invalidated when its `TLI` reference becomes stale. (cherry picked from commit 7886257)
BasicAAResultholds a reference toTargetLibraryInfobut itsinvalidate()function did not checkTargetLibraryAnalysis. When the pass manager destroyed and re-createdTLI(e.g. duringCGSCCinvalidation orFAM.clear()),BasicAAResultsurvived with a danglingTLIreference.This was exposed by #157495 which added
aliasErrno(), the first code path that dereferencesTLIfromBasicAAResultduring theCGSCCpipeline, causing a AV when compiling Rust's core library on Arm64 Windows.This change adds
TargetLibraryAnalysisto the invalidation check soBasicAAResultis properly invalidated when itsTLIreference becomes stale.