-
Notifications
You must be signed in to change notification settings - Fork 11k
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
[NewPM] Fix a nasty bug with analysis invalidation in the new PM.
The issue here is that we actually allow CGSCC passes to mutate IR (and therefore invalidate analyses) outside of the current SCC. At a minimum, we need to support mutating parent and ancestor SCCs to support the ArgumentPromotion pass which rewrites all calls to a function. However, the analysis invalidation infrastructure is heavily based around not needing to invalidate the same IR-unit at multiple levels. With Loop passes for example, they don't invalidate other Loops. So we need to customize how we handle CGSCC invalidation. Doing this without gratuitously re-running analyses is even harder. I've avoided most of these by using an out-of-band preserved set to accumulate the cross-SCC invalidation, but it still isn't perfect in the case of re-visiting the same SCC repeatedly *but* it coming off the worklist. Unclear how important this use case really is, but I wanted to call it out. Another wrinkle is that in order for this to successfully propagate to function analyses, we have to make sure we have a proxy from the SCC to the Function level. That requires pre-creating the necessary proxy. The motivating test case now works cleanly and is added for ArgumentPromotion. Thanks for the review from Philip and Wei! Differential Revision: https://reviews.llvm.org/D59869 llvm-svn: 357137
- Loading branch information
Showing
8 changed files
with
298 additions
and
184 deletions.
There are no files selected for viewing
Large diffs are not rendered by default.
Oops, something went wrong.
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,50 @@ | ||
; Check that when argument promotion changes a function in some parent node of | ||
; the call graph, any analyses that happened to be cached for that function are | ||
; actually invalidated. We are using `demanded-bits` here because when printed | ||
; it will end up caching a value for every instruction, making it easy to | ||
; detect the instruction-level changes that will fail here. With improper | ||
; invalidation this will crash in the second printer as it tries to reuse | ||
; now-invalid demanded bits. | ||
; | ||
; RUN: opt < %s -passes='function(print<demanded-bits>),cgscc(argpromotion,function(print<demanded-bits>))' -S | FileCheck %s | ||
|
||
@G = constant i32 0 | ||
|
||
define internal i32 @a(i32* %x) { | ||
; CHECK-LABEL: define internal i32 @a( | ||
; CHECK-SAME: i32 %[[V:.*]]) { | ||
; CHECK-NEXT: entry: | ||
; CHECK-NEXT: ret i32 %[[V]] | ||
; CHECK-NEXT: } | ||
entry: | ||
%v = load i32, i32* %x | ||
ret i32 %v | ||
} | ||
|
||
define i32 @b() { | ||
; CHECK-LABEL: define i32 @b() | ||
; CHECK-NEXT: entry: | ||
; CHECK-NEXT: %[[L:.*]] = load i32, i32* @G | ||
; CHECK-NEXT: %[[V:.*]] = call i32 @a(i32 %[[L]]) | ||
; CHECK-NEXT: ret i32 %[[V]] | ||
; CHECK-NEXT: } | ||
entry: | ||
%v = call i32 @a(i32* @G) | ||
ret i32 %v | ||
} | ||
|
||
define i32 @c() { | ||
; CHECK-LABEL: define i32 @c() | ||
; CHECK-NEXT: entry: | ||
; CHECK-NEXT: %[[L:.*]] = load i32, i32* @G | ||
; CHECK-NEXT: %[[V1:.*]] = call i32 @a(i32 %[[L]]) | ||
; CHECK-NEXT: %[[V2:.*]] = call i32 @b() | ||
; CHECK-NEXT: %[[RESULT:.*]] = add i32 %[[V1]], %[[V2]] | ||
; CHECK-NEXT: ret i32 %[[RESULT]] | ||
; CHECK-NEXT: } | ||
entry: | ||
%v1 = call i32 @a(i32* @G) | ||
%v2 = call i32 @b() | ||
%result = add i32 %v1, %v2 | ||
ret i32 %result | ||
} |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters