llvm/test/Transforms/DeadStoreElimination/fence.ll

   1 ; RUN: opt -S -passes=dse < %s | FileCheck %s
   2
   3 ; We conservative choose to prevent dead store elimination
   4 ; across release or stronger fences.  It's not required
   5 ; (since the must still be a race on %addd.i), but
   6 ; it is conservatively correct.  A legal optimization
   7 ; could hoist the second store above the fence, and then
   8 ; DSE one of them.
   9 define void @test1(ptr %addr.i) {
  10 ; CHECK-LABEL: @test1
  11 ; CHECK: store i32 5
  12 ; CHECK: fence
  13 ; CHECK: store i32 5
  14 ; CHECK: ret
  15   store i32 5, ptr %addr.i, align 4
  16   fence release
  17   store i32 5, ptr %addr.i, align 4
  18   ret void
  19 }
  20
  21 ; Same as previous, but with different values.  If we ever optimize
  22 ; this more aggressively, this allows us to check that the correct
  23 ; store is retained (the 'i32 1' store in this case)
  24 define void @test1b(ptr %addr.i) {
  25 ; CHECK-LABEL: @test1b
  26 ; CHECK: store i32 42
  27 ; CHECK: fence release
  28 ; CHECK: store i32 1
  29 ; CHECK: ret
  30   store i32 42, ptr %addr.i, align 4
  31   fence release
  32   store i32 1, ptr %addr.i, align 4
  33   ret void
  34 }
  35
  36 ; We *could* DSE across this fence, but don't.  No other thread can
  37 ; observe the order of the acquire fence and the store.
  38 define void @test2(ptr %addr.i) {
  39 ; CHECK-LABEL: @test2
  40 ; CHECK: store
  41 ; CHECK: fence
  42 ; CHECK: store
  43 ; CHECK: ret
  44   store i32 5, ptr %addr.i, align 4
  45   fence acquire
  46   store i32 5, ptr %addr.i, align 4
  47   ret void
  48 }