llvm/test/Transforms/NewGVN/fence-xfail.ll

   1 ; XFAIL: *
   2 ; RUN: opt -S -basic-aa -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