1 ; XFAIL: * 2 ; RUN: opt -S -basicaa -newgvn < %s | FileCheck %s 3 4 @a = external constant i32 5 ; We can value forward across the fence since we can (semantically) 6 ; reorder the following load before the fence. 7 define i32 @test(i32* %addr.i) { 8 ; CHECK-LABEL: @test 9 ; CHECK: store 10 ; CHECK: fence 11 ; CHECK-NOT: load 12 ; CHECK: ret 13 store i32 5, i32* %addr.i, align 4 14 fence release 15 %a = load i32, i32* %addr.i, align 4 16 ret i32 %a 17 } 18 19 ; Same as above 20 define i32 @test2(i32* %addr.i) { 21 ; CHECK-LABEL: @test2 22 ; CHECK-NEXT: fence 23 ; CHECK-NOT: load 24 ; CHECK: ret 25 %a = load i32, i32* %addr.i, align 4 26 fence release 27 %a2 = load i32, i32* %addr.i, align 4 28 %res = sub i32 %a, %a2 29 ret i32 %res 30 } 31 32 ; We can not value forward across an acquire barrier since we might 33 ; be syncronizing with another thread storing to the same variable 34 ; followed by a release fence. This is not so much enforcing an 35 ; ordering property (though it is that too), but a liveness 36 ; property. We expect to eventually see the value of store by 37 ; another thread when spinning on that location. 38 define i32 @test3(i32* noalias %addr.i, i32* noalias %otheraddr) { 39 ; CHECK-LABEL: @test3 40 ; CHECK: load 41 ; CHECK: fence 42 ; CHECK: load 43 ; CHECK: ret i32 %res 44 ; the following code is intented to model the unrolling of 45 ; two iterations in a spin loop of the form: 46 ; do { fence acquire: tmp = *%addr.i; ) while (!tmp); 47 ; It's hopefully clear that allowing PRE to turn this into: 48 ; if (!*%addr.i) while(true) {} would be unfortunate 49 fence acquire 50 %a = load i32, i32* %addr.i, align 4 51 fence acquire 52 %a2 = load i32, i32* %addr.i, align 4 53 %res = sub i32 %a, %a2 54 ret i32 %res 55 } 56 57 ; We can forward the value forward the load 58 ; across both the fences, because the load is from 59 ; a constant memory location. 60 define i32 @test4(i32* %addr) { 61 ; CHECK-LABEL: @test4 62 ; CHECK-NOT: load 63 ; CHECK: fence release 64 ; CHECK: store 65 ; CHECK: fence seq_cst 66 ; CHECK: ret i32 0 67 %var = load i32, i32* @a 68 fence release 69 store i32 42, i32* %addr, align 8 70 fence seq_cst 71 %var2 = load i32, i32* @a 72 %var3 = sub i32 %var, %var2 73 ret i32 %var3 74 } 75 76 ; Another example of why forwarding across an acquire fence is problematic 77 ; can be seen in a normal locking operation. Say we had: 78 ; *p = 5; unlock(l); lock(l); use(p); 79 ; forwarding the store to p would be invalid. A reasonable implementation 80 ; of unlock and lock might be: 81 ; unlock() { atomicrmw sub %l, 1 unordered; fence release } 82 ; lock() { 83 ; do { 84 ; %res = cmpxchg %p, 0, 1, monotonic monotonic 85 ; } while(!%res.success) 86 ; fence acquire; 87 ; } 88 ; Given we chose to forward across the release fence, we clearly can't forward 89 ; across the acquire fence as well. 90 91
