1
0
mirror of https://github.com/RPCS3/llvm-mirror.git synced 2024-10-20 19:42:54 +02:00
llvm-mirror/test/Transforms/MergeFunc/constant-entire-value.ll

43 lines
1.1 KiB
LLVM
Raw Normal View History

Improve the determinism of MergeFunctions Summary: Merge functions previously relied on unsigned comparisons of pointer values to order functions. This caused observable non-determinism in the compiler for large bitcode programs. Basically, opt -mergefuncs program.bc | md5sum produces different hashes when run repeatedly on the same machine. Differing output was observed on three large bitcodes, but it was less frequent on the smallest file. It is possible that this only manifests on the large inputs, hence remaining undetected until now. This patch fixes this by removing (almost, see below) all places where comparisons between pointers are used to order functions. Most of these changes are local, but the comparison of global values requires assigning an identifier to each local in the order it is visited. This is very similar to the way the comparison function identifies Value*'s defined within a function. Because the order of visiting the functions and their subparts is deterministic, the identifiers assigned to the globals will be as well, and the order of functions will be deterministic. With these changes, there is no more observed non-determinism. There is also only minor slowdowns (negligible to 4%) compared to the baseline, which is likely a result of the fact that global comparisons involve hash lookups and not just pointer comparisons. The one caveat so far is that programs containing BlockAddress constants can still be non-deterministic. It is not clear what the right solution is here. In particular, even if the global numbers are used to order by function, we still need a way to order the BasicBlock*'s. Unfortunately, we cannot just bail out and fail to order the functions or consider them equal, because we require a total order over functions. Note that programs with BlockAddress constants are relatively rare, so the impact of leaving this in is minor as long as this pass is opt-in. Author: jrkoenig Reviewers: nlewycky, jfb, dschuff Subscribers: jevinskie, llvm-commits, chapuni Differential revision: http://reviews.llvm.org/D12168 llvm-svn: 245762
2015-08-22 01:27:24 +02:00
; RUN: opt -S -mergefunc < %s | FileCheck %s
; RUN: opt -S -mergefunc < %s | FileCheck -check-prefix=NOPLUS %s
; This makes sure that zeros in constants don't cause problems with string based
; memory comparisons
define internal i32 @sum(i32 %x, i32 %y) {
; CHECK-LABEL: @sum
%sum = add i32 %x, %y
%1 = extractvalue [3 x i32] [ i32 3, i32 0, i32 2 ], 2
%sum2 = add i32 %sum, %1
%sum3 = add i32 %sum2, %y
ret i32 %sum3
}
define internal i32 @add(i32 %x, i32 %y) {
; CHECK-LABEL: @add
%sum = add i32 %x, %y
%1 = extractvalue [3 x i32] [ i32 3, i32 0, i32 1 ], 2
%sum2 = add i32 %sum, %1
%sum3 = add i32 %sum2, %y
ret i32 %sum3
}
define internal i32 @plus(i32 %x, i32 %y) {
; NOPLUS-NOT: @plus
%sum = add i32 %x, %y
%1 = extractvalue [3 x i32] [ i32 3, i32 0, i32 5 ], 2
%sum2 = add i32 %sum, %1
%sum3 = add i32 %sum2, %y
ret i32 %sum3
}
define internal i32 @next(i32 %x, i32 %y) {
; CHECK-LABEL: @next
%sum = add i32 %x, %y
%1 = extractvalue [3 x i32] [ i32 3, i32 0, i32 5 ], 2
%sum2 = add i32 %sum, %1
%sum3 = add i32 %sum2, %y
ret i32 %sum3
}