mirror of
https://github.com/RPCS3/llvm-mirror.git
synced 2024-11-25 12:12:47 +01:00
8b737bdfec
If a module has many values that need to be resolved by ResolvedUndefsIn, compilation takes quadratic time overall. Solve should do a small amount of work, since not much is added to the worklists each time markOverdefined is called. But ResolvedUndefsIn is linear over the length of the function/module, so resolving one undef at a time is quadratic in general. To solve this, make ResolvedUndefsIn resolve every undef value at once, instead of resolving them one at a time. This loses a little optimization power, but can be a lot faster. We still need a loop around ResolvedUndefsIn because markOverdefined could change the set of blocks that are live. That should be uncommon, hopefully. We could optimize it by tracking which blocks transition from dead to live, instead of iterating over the whole module to find them. But I'll leave that for later. (The whole function will become a lot simpler once we start pruning branches on undef.) The regression test changes seem minor. The specific cases in question could probably be optimized with a bit more work, but they seem like edge cases that don't really matter. Fixes an "infinite" compile issue my team found on an internal workoad. Differential Revision: https://reviews.llvm.org/D89080
13 lines
265 B
LLVM
13 lines
265 B
LLVM
; RUN: opt < %s -sccp -S | grep "ret i32 %X"
|
|
|
|
; This function definitely returns 1, even if we don't know the direction
|
|
; of the branch.
|
|
|
|
define i32 @foo() {
|
|
br i1 undef, label %T, label %T
|
|
T: ; preds = %0, %0
|
|
%X = add i32 0, 1 ; <i32> [#uses=1]
|
|
ret i32 %X
|
|
}
|
|
|