6502/llvm-6502
1
0
Fork 0
mirror of https://github.com/c64scene-ar/llvm-6502.git synced 2024-12-17 18:31:04 +00:00
Code Issues Projects Releases Wiki Activity
5eba90a861
llvm-6502/test/Transforms/ConstantHoisting/X86/phi.ll

117 lines
3.0 KiB
LLVM
Raw Normal View History

ConstantHoisting: We can't insert instructions directly in front of a PHI node. Insert before the terminating instruction of the dominating block instead. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@200218 91177308-0d34-0410-b5e6-96231b3b80d8
2014-01-27 13:11:43 +00:00
; RUN: opt -S -consthoist < %s | FileCheck %s
target datalayout = "e-m:o-i64:64-f80:128-n8:16:32:64-S128"
target triple = "x86_64-apple-macosx10.9.0"
; PR18626
define i8* @test1(i1 %cmp, i64* %tmp) {
entry:
call void @foo(i8* inttoptr (i64 68719476735 to i8*))
br i1 %cmp, label %if.end, label %return
if.end: ; preds = %bb1
call void @foo(i8* inttoptr (i64 68719476736 to i8*))
br label %return
return:
%retval.0 = phi i8* [ null, %entry ], [ inttoptr (i64 68719476736 to i8*), %if.end ]
store i64 1172321806, i64* %tmp
ret i8* %retval.0
; CHECK-LABEL: @test1
[Constant Hoisting] Change the algorithm to only track constants for instructions. Originally the algorithm would search for expensive constants and track their users, which could be instructions and constant expressions. This change only tracks the constants for instructions, but constant expressions are indirectly covered too. If an operand is an constant expression, then we look through the expression to find anny expensive constants. The algorithm keep now track of the instruction and the operand index where the constant is used. This allows more precise hoisting of constant materialization code for PHI instructions, because we only hoist to the basic block of the incoming operand. Before we had to find the idom of all PHI operands and hoist the materialization code there. This also makes updating of instructions easier. Before we had to keep track of the original constant, find it in the instructions, and then replace it. Now we can just simply update the operand. Related to <rdar://problem/16381500> git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@204433 91177308-0d34-0410-b5e6-96231b3b80d8
2014-03-21 06:04:36 +00:00
; CHECK: if.end:
[Constant Hoisting] Make the constant materialization cost operand dependent Extend the target hook to take also the operand index into account when calculating the cost of the constant materialization. Related to <rdar://problem/16381500> git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@204435 91177308-0d34-0410-b5e6-96231b3b80d8
2014-03-21 06:04:45 +00:00
; CHECK: %2 = inttoptr i64 %const to i8*
; CHECK-NEXT: br
[Constant Hoisting] Change the algorithm to only track constants for instructions. Originally the algorithm would search for expensive constants and track their users, which could be instructions and constant expressions. This change only tracks the constants for instructions, but constant expressions are indirectly covered too. If an operand is an constant expression, then we look through the expression to find anny expensive constants. The algorithm keep now track of the instruction and the operand index where the constant is used. This allows more precise hoisting of constant materialization code for PHI instructions, because we only hoist to the basic block of the incoming operand. Before we had to find the idom of all PHI operands and hoist the materialization code there. This also makes updating of instructions easier. Before we had to keep track of the original constant, find it in the instructions, and then replace it. Now we can just simply update the operand. Related to <rdar://problem/16381500> git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@204433 91177308-0d34-0410-b5e6-96231b3b80d8
2014-03-21 06:04:36 +00:00
; CHECK: return:
[Constant Hoisting] Make the constant materialization cost operand dependent Extend the target hook to take also the operand index into account when calculating the cost of the constant materialization. Related to <rdar://problem/16381500> git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@204435 91177308-0d34-0410-b5e6-96231b3b80d8
2014-03-21 06:04:45 +00:00
; CHECK-NEXT: %retval.0 = phi i8* [ null, %entry ], [ %2, %if.end ]
ConstantHoisting: We can't insert instructions directly in front of a PHI node. Insert before the terminating instruction of the dominating block instead. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@200218 91177308-0d34-0410-b5e6-96231b3b80d8
2014-01-27 13:11:43 +00:00
}
define void @test2(i1 %cmp, i64** %tmp) {
entry:
call void @foo(i8* inttoptr (i64 68719476736 to i8*))
br i1 %cmp, label %if.end, label %return
if.end: ; preds = %bb1
call void @foo(i8* inttoptr (i64 68719476736 to i8*))
br label %return
return:
store i64* inttoptr (i64 68719476735 to i64*), i64** %tmp
ret void
; CHECK-LABEL: @test2
; CHECK: return:
; CHECK-NEXT: %const_mat = add i64 %const, -1
; CHECK-NEXT: inttoptr i64 %const_mat to i64*
}
declare void @foo(i8*)
[Constant Hoisting] Fix insertion point for constant materialization. The bitcast instruction during constant materialization was not placed correcly in the presence of phi nodes. This commit fixes the insertion point to be in the idom instead. This fixes PR18768 git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@201009 91177308-0d34-0410-b5e6-96231b3b80d8
2014-02-08 00:20:49 +00:00
; PR18768
define i32 @test3(i1 %c) {
entry:
br i1 %c, label %if.then, label %if.end3
if.then: ; preds = %entry
br label %if.end3
if.end3: ; preds = %if.then, %entry
%d.0 = phi i32* [ inttoptr (i64 985162435264511 to i32*), %entry ], [ null, %if.then ]
%cmp4 = icmp eq i32* %d.0, inttoptr (i64 985162435264511 to i32*)
%cmp6 = icmp eq i32* %d.0, inttoptr (i64 985162418487296 to i32*)
%or = or i1 %cmp4, %cmp6
br i1 %or, label %if.then8, label %if.end9
if.then8: ; preds = %if.end3
ret i32 1
if.end9: ; preds = %if.then8, %if.end3
ret i32 undef
}
[Constant Hoisting] Fix multiple entries for the same basic block in PHI nodes. A PHI node usually has only one value/basic block pair per incoming basic block. In the case of a switch statement it is possible that a following PHI node may have more than one such pair per incoming basic block. E.g.: %0 = phi i64 [ 123456, %case2 ], [ 654321, %Entry ], [ 654321, %Entry ] This is valid and the verfier doesn't complain, because both values are the same. Constant hoisting materializes the constant for each operand separately and the value is still the same, but the variable names have changed. As a result the verfier can't recognize anymore that they are the same value and complains. This fix adds special update code for PHI node in constant hoisting to prevent this corner case. This fixes <rdar://problem/16394449> git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@204537 91177308-0d34-0410-b5e6-96231b3b80d8
2014-03-22 01:49:27 +00:00
; <rdar://problem/16394449>
define i64 @switch_test1(i64 %a) {
; CHECK-LABEL: @switch_test1
; CHECK: %0 = phi i64 [ %const, %case2 ], [ %const_mat, %Entry ], [ %const_mat, %Entry ]
Entry:
%sel = add i64 %a, 4519019440
switch i64 %sel, label %fail [
i64 462, label %continuation
i64 449, label %case2
i64 443, label %continuation
]
case2:
br label %continuation
continuation:
%0 = phi i64 [ 4519019440, %case2 ], [ 4519019460, %Entry ], [ 4519019460, %Entry ]
ret i64 0;
fail:
ret i64 -1;
}
define i64 @switch_test2(i64 %a) {
; CHECK-LABEL: @switch_test2
; CHECK: %2 = phi i64* [ %1, %case2 ], [ %0, %Entry ], [ %0, %Entry ]
Entry:
%sel = add i64 %a, 4519019440
switch i64 %sel, label %fail [
i64 462, label %continuation
i64 449, label %case2
i64 443, label %continuation
]
case2:
br label %continuation
continuation:
%0 = phi i64* [ inttoptr(i64 4519019440 to i64*), %case2 ], [ inttoptr(i64 4519019460 to i64*), %Entry ], [ inttoptr(i64 4519019460 to i64*), %Entry ]
ret i64 0;
fail:
ret i64 -1;
}
Reference in New Issue Copy Permalink