50b2a113db
As a result of -ftrivial-auto-var-init, clang generates instructions to set alloca'd memory to a given pattern, right after the allocation site. In some cases, this (somehow costly) operation could be delayed, leading to conditional execution in some cases. This is not an uncommon situation: it happens ~500 times on the cPython code base, and much more on the LLVM codebase. The benefit greatly varies on the execution path, but it should not regress on performance. This is a recommit of cca01008cc31a891d0ec70aff2201b25d05d8f1b with MemorySSA update fixes. Differential Revision: https://reviews.llvm.org/D137707
37 lines
1.1 KiB
LLVM
37 lines
1.1 KiB
LLVM
; NOTE: Assertions have been autogenerated by utils/update_test_checks.py
|
|
; RUN: opt < %s -S -passes='move-auto-init' -verify-memoryssa | FileCheck %s
|
|
|
|
target datalayout = "e-m:e-p270:32:32-p271:32:32-p272:64:64-i64:64-f80:128-n8:16:32:64-S128"
|
|
|
|
define void @foo(i32 %x) {
|
|
; CHECK-LABEL: @foo(
|
|
; CHECK-NEXT: entry:
|
|
; CHECK-NEXT: [[VAL:%.*]] = alloca i32, align 4
|
|
; CHECK-NEXT: [[TOBOOL:%.*]] = icmp ne i32 [[X:%.*]], 0
|
|
; CHECK-NEXT: br i1 [[TOBOOL]], label [[IF_THEN:%.*]], label [[IF_END:%.*]]
|
|
; CHECK: if.then:
|
|
; CHECK-NEXT: store i32 -1431655766, ptr [[VAL]], align 4, !annotation !0
|
|
; CHECK-NEXT: call void @dump(ptr [[VAL]])
|
|
; CHECK-NEXT: br label [[IF_END]]
|
|
; CHECK: if.end:
|
|
; CHECK-NEXT: ret void
|
|
;
|
|
|
|
entry:
|
|
%val = alloca i32, align 4
|
|
store i32 -1431655766, ptr %val, align 4, !annotation !0
|
|
%tobool = icmp ne i32 %x, 0
|
|
br i1 %tobool, label %if.then, label %if.end
|
|
|
|
if.then: ; preds = %entry
|
|
call void @dump(ptr %val)
|
|
br label %if.end
|
|
|
|
if.end: ; preds = %if.then, %entry
|
|
ret void
|
|
}
|
|
|
|
declare void @dump(ptr)
|
|
|
|
!0 = !{!"auto-init"}
|