91 lines · plain
1; XFAIL: *2; RUN: opt -S -passes=newgvn < %s | FileCheck %s3 4@a = external constant i325; We can value forward across the fence since we can (semantically) 6; reorder the following load before the fence.7define i32 @test(ptr %addr.i) {8; CHECK-LABEL: @test9; CHECK: store10; CHECK: fence11; CHECK-NOT: load12; CHECK: ret13 store i32 5, ptr %addr.i, align 414 fence release15 %a = load i32, ptr %addr.i, align 416 ret i32 %a17}18 19; Same as above20define i32 @test2(ptr %addr.i) {21; CHECK-LABEL: @test222; CHECK-NEXT: fence23; CHECK-NOT: load24; CHECK: ret25 %a = load i32, ptr %addr.i, align 426 fence release27 %a2 = load i32, ptr %addr.i, align 428 %res = sub i32 %a, %a229 ret i32 %res30}31 32; We can not value forward across an acquire barrier since we might33; be syncronizing with another thread storing to the same variable34; followed by a release fence. This is not so much enforcing an35; ordering property (though it is that too), but a liveness 36; property. We expect to eventually see the value of store by37; another thread when spinning on that location. 38define i32 @test3(ptr noalias %addr.i, ptr noalias %otheraddr) {39; CHECK-LABEL: @test340; CHECK: load41; CHECK: fence42; CHECK: load43; CHECK: ret i32 %res44 ; the following code is intented to model the unrolling of45 ; 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 unfortunate49 fence acquire50 %a = load i32, ptr %addr.i, align 451 fence acquire52 %a2 = load i32, ptr %addr.i, align 453 %res = sub i32 %a, %a254 ret i32 %res55}56 57; We can forward the value forward the load58; across both the fences, because the load is from59; a constant memory location.60define i32 @test4(ptr %addr) {61; CHECK-LABEL: @test462; CHECK-NOT: load63; CHECK: fence release64; CHECK: store65; CHECK: fence seq_cst66; CHECK: ret i32 067 %var = load i32, ptr @a68 fence release69 store i32 42, ptr %addr, align 870 fence seq_cst71 %var2 = load i32, ptr @a72 %var3 = sub i32 %var, %var273 ret i32 %var374}75 76; Another example of why forwarding across an acquire fence is problematic77; 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 implementation80; 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 monotonic85; } while(!%res.success)86; fence acquire;87; }88; Given we chose to forward across the release fence, we clearly can't forward89; across the acquire fence as well.90 91