43436993f4
This was introduced in 030f02021b as
an alleged compile-time optimization. In reality, trying to constant
fold instructions is more expensive than just hoisting them. In a
standard pipeline, LICM tends to run either after a run of
LoopInstSimplify or InstCombine, so LICM doesn't really see constant
foldable instructions in the first place, and the attempted fold
is futile.
This makes for a very minor compile-time improvement.
Differential Revision: https://reviews.llvm.org/D149134
30 lines
922 B
LLVM
30 lines
922 B
LLVM
; NOTE: Assertions have been autogenerated by utils/update_test_checks.py UTC_ARGS: --version 2
|
|
; RUN: opt -S -passes=licm,simple-loop-unswitch,licm < %s | FileCheck %s
|
|
|
|
declare void @llvm.experimental.guard(i1, ...)
|
|
|
|
define void @test() {
|
|
; CHECK-LABEL: define void @test() {
|
|
; CHECK-NEXT: entry:
|
|
; CHECK-NEXT: [[TMP0:%.*]] = icmp ult i32 0, 400
|
|
; CHECK-NEXT: call void (i1, ...) @llvm.experimental.guard(i1 [[TMP0]], i32 9) [ "deopt"() ]
|
|
; CHECK-NEXT: br label [[HEADER:%.*]]
|
|
; CHECK: header.loopexit:
|
|
; CHECK-NEXT: br label [[HEADER]]
|
|
; CHECK: header:
|
|
; CHECK-NEXT: br label [[LOOP:%.*]]
|
|
; CHECK: loop:
|
|
; CHECK-NEXT: br i1 true, label [[HEADER_LOOPEXIT:%.*]], label [[LOOP]]
|
|
;
|
|
entry:
|
|
br label %header
|
|
|
|
header:
|
|
br label %loop
|
|
|
|
loop:
|
|
%0 = icmp ult i32 0, 400
|
|
call void (i1, ...) @llvm.experimental.guard(i1 %0, i32 9) [ "deopt"() ]
|
|
br i1 undef, label %header, label %loop
|
|
}
|