SimplifyCFG SinkCommonCodeFromPredecessors: Also sink function calls without used results (PR41259)

[hans]

Summary

The code was previously checking that candidates for sinking had exactly one use or were a store instruction (which can't have uses). This meant we could sink call instructions only if they had a use.

That limitation seemed a bit arbitrary, so this patch changes it to "instruction has zero or one use" which seems more natural and removes the need to special-case stores.

Please take a look!

[hans]

llvm/lib/Transforms/Utils/SimplifyCFG.cpp

1474

Actually this isn't quite right. I0 might not have a use but one of the other instructions might, or vice-versa. Same problem for the checks below...

[hans]

Checking that the instructions have the same number of uses. This passes a clang bootstrap build.

[hans]

Maybe Ben wants to take a look?

[dmgreen]

Looks like a good improvement to me.

[hans]

In D59936#1449737, @dmgreen wrote:

Looks like a good improvement to me.

Thanks!

[uabelho]

Hi,

When looking at some code changes for my out-of-tree target with this commit I noticed a change that I thought I'd ask if you think
is good or not.

With this change we now seem to sink e.g. calls to @llvm.lifetime.end? It returns void, and thus has 0 uses, and as far as I understand
such calls were not sinked before? Is this on purpose and is that good? In general I guess it's good to do lifetime.end at soon as possible?

(And I suppose there are also a whole bunch of other intrinsics that also return void that can be sinked now, I've no idea if that
can cause problems somewhere?)

[hans]

In D59936#1452733, @uabelho wrote:

When looking at some code changes for my out-of-tree target with this commit I noticed a change that I thought I'd ask if you think
is good or not.

With this change we now seem to sink e.g. calls to @llvm.lifetime.end? It returns void, and thus has 0 uses, and as far as I understand
such calls were not sinked before? Is this on purpose and is that good? In general I guess it's good to do lifetime.end at soon as possible?

(And I suppose there are also a whole bunch of other intrinsics that also return void that can be sinked now, I've no idea if that
can cause problems somewhere?)

It's not on purpose in the sense that I was targeting the lifetime intrinsics, but it's showing my change working as intended.

For the lifetime intrinsics, I don't think this really matters. As you say, it's good to do lifetime.end as soon as possible, so sinking them in general doesn't make sense, but I also don't think this matters much here because they can't be sunk very far, i.e. I don't see how this sinking could actually extend the lifetime.

[uabelho]

In D59936#1452754, @hans wrote:

In D59936#1452733, @uabelho wrote:

When looking at some code changes for my out-of-tree target with this commit I noticed a change that I thought I'd ask if you think
is good or not.

With this change we now seem to sink e.g. calls to @llvm.lifetime.end? It returns void, and thus has 0 uses, and as far as I understand
such calls were not sinked before? Is this on purpose and is that good? In general I guess it's good to do lifetime.end at soon as possible?

(And I suppose there are also a whole bunch of other intrinsics that also return void that can be sinked now, I've no idea if that
can cause problems somewhere?)

It's not on purpose in the sense that I was targeting the lifetime intrinsics, but it's showing my change working as intended.

For the lifetime intrinsics, I don't think this really matters. As you say, it's good to do lifetime.end as soon as possible, so sinking them in general doesn't make sense, but I also don't think this matters much here because they can't be sunk very far, i.e. I don't see how this sinking could actually extend the lifetime.

Ok, yes I don't know, when I saw it it just worried me that perhaps intrinsics like lifetime.end was the "arbitrary" reason that we didn't allow to sink zero-use instructions before.

[hans]

For the lifetime intrinsics, I don't think this really matters. As you say, it's good to do lifetime.end as soon as possible, so sinking them in general doesn't make sense, but I also don't think this matters much here because they can't be sunk very far, i.e. I don't see how this sinking could actually extend the lifetime.

Ok, yes I don't know, when I saw it it just worried me that perhaps intrinsics like lifetime.end was the "arbitrary" reason that we didn't allow to sink zero-use instructions before.

The way I imagine it happened was that when support for sinking was added, it carefully handled the case of uses, dealing with the PHI node and so on. Then someone realized we couldn't sink store instructions because they don't have uses, and added a special case for them.

[dmgreen]

We saw some good looking codesize decreases from this, by the way. Just to add to the "this patch does good" side of the argument :)

For lifetime.end, if we start producing llvm.lifetime.end(phi(x, y, z)) then I could see that potentially being worse. I have no evidence of that happening though. And it may even be better if it allows further sinking.

[xbolva00]

Maybe you can add more tests with these intrinsics?

[dlj]

This revision causes tests to fail under ASAN. After some investigation (with Chandler's help), it looks like the safest course of action is to revert. We're following up with Hans separately.

Reverted as r357667.

[hans]

In D59936#1454346, @dlj wrote:

This revision causes tests to fail under ASAN. After some investigation (with Chandler's help), it looks like the safest course of action is to revert. We're following up with Hans separately.

Reverted as r357667.

Thanks, and sorry for the breakage.

For my own notes, the internal bug tracker entry is 129905821. The V8 team also saw asan errors from ICU due to this, tracked in https://bugs.chromium.org/p/v8/issues/detail?id=9086 I'll try to investigate there to keep this in the open.

[hans]

In D59936#1454565, @hans wrote:

In D59936#1454346, @dlj wrote:

This revision causes tests to fail under ASAN. After some investigation (with Chandler's help), it looks like the safest course of action is to revert. We're following up with Hans separately.

Reverted as r357667.

Thanks, and sorry for the breakage.

For my own notes, the internal bug tracker entry is 129905821. The V8 team also saw asan errors from ICU due to this, tracked in https://bugs.chromium.org/p/v8/issues/detail?id=9086 I'll try to investigate there to keep this in the open.

And https://bugs.llvm.org/show_bug.cgi?id=41481 for the asan issue.

This points to an interesting point that was raised here earlier though:

In D59936#1452855, @dmgreen wrote:

For lifetime.end, if we start producing llvm.lifetime.end(phi(x, y, z)) then I could see that potentially being worse. I have no evidence of that happening though. And it may even be better if it allows further sinking.

We now know that it did happen :-) In the case with the asan false positive it was two lifetime.start intrinsics sunk into one with a select argument.

But I think that is working as intended. It doesn't break any invariants with the intrinsics that I know of, and I don't think it will generate worse code either. In fact, I think seeing those lifetime intrinsics getting sunk shows that the intrinsics were blocking sinking optimizations that we are now able to perform.

[dmgreen]

What are you thinking is best here? I agree that lifetime.end shouldn't prohibit optimisations. Do you think it's best to fix asan and go with this as-is, or to try and prevent sinking if it will only sink a lifetime.time?

[hans]

In D59936#1467261, @dmgreen wrote:

What are you thinking is best here? I agree that lifetime.end shouldn't prohibit optimisations. Do you think it's best to fix asan and go with this as-is, or to try and prevent sinking if it will only sink a lifetime.time?

I think it's best to fix asan and re-commit this as-is. I'll do that once the asan fix (r358478) has baked a little.

[dmgreen]

OK. Sounds good to me. We can always change it if necessary.

[hans]

Re-committed in r358483.

clang/test/CodeGenCXX/nrvo.cpp

if (B)
     return y;
   return x;
 
   // CHECK: call {{.*}} @_ZN1XC1Ev
   // CHECK-NEXT: {{.*}} getelementptr inbounds %class.X, %class.X* %y, i32 0, i32 0
   // CHECK-NEXT: call void @llvm.lifetime.start
   // CHECK-NEXT: call {{.*}} @_ZN1XC1Ev
   // CHECK: call {{.*}} @_ZN1XC1ERKS_
-  // CHECK: call {{.*}} @_ZN1XC1ERKS_
   // CHECK: call {{.*}} @_ZN1XD1Ev
   // CHECK-NEXT: call void @llvm.lifetime.end
   // CHECK: call {{.*}} @_ZN1XD1Ev
   // CHECK-NEXT: call void @llvm.lifetime.end
   // CHECK: ret void
 
   // The block ordering in the -fexceptions IR is unfortunate.
 

clang/test/CodeGenCXX/stack-reuse-exceptions.cpp

 // RUN: %clang_cc1 -triple x86_64-unknown-linux-gnu %s -o - -emit-llvm -O1 \
-// RUN:     -fexceptions -fcxx-exceptions | FileCheck %s
+// RUN:     -fexceptions -fcxx-exceptions -mllvm -simplifycfg-sink-common=false | FileCheck %s
 //
 // We should emit lifetime.ends for these temporaries in both the 'exception'
 // and 'normal' paths in functions.
 //
 // -O1 is necessary to make lifetime markers appear.
 
 struct Large {
   int cs[32];

clang/test/CodeGenObjC/exceptions.m

-// RUN: %clang_cc1 -triple x86_64-apple-darwin10 -fobjc-runtime=macosx-fragile-10.5 -emit-llvm -fobjc-exceptions -O2 -o - %s | FileCheck %s
+// RUN: %clang_cc1 -triple x86_64-apple-darwin10 -fobjc-runtime=macosx-fragile-10.5 -emit-llvm -fobjc-exceptions -mllvm -simplifycfg-sink-common=false -O2 -o - %s | FileCheck %s
 //
 // <rdar://problem/7471679> [irgen] [eh] Exception code built with clang (x86_64) crashes
 
 // Just check that we don't emit any dead blocks.
 @interface NSArray @end
 void f0() {
   @try {
     @try {

llvm/lib/Transforms/Utils/SimplifyCFG.cpp

 // All instructions in Insts belong to different blocks that all unconditionally
 // branch to a common successor. Analyze each instruction and return true if it
 // would be possible to sink them into their successor, creating one common
 // instruction instead. For every value that would be required to be provided by
 // PHI node (because an operand varies in each input block), add to PHIOperands.
 static bool canSinkInstructions(
     ArrayRef<Instruction *> Insts,
     DenseMap<Instruction *, SmallVector<Value *, 4>> &PHIOperands) {
-  // Prune out obviously bad instructions to move. Any non-store instruction
-  // must have exactly one use, and we check later that use is by a single,
-  // common PHI instruction in the successor.
+  // Prune out obviously bad instructions to move. Each instruction must have
+  // exactly zero or one use, and we check later that use is by a single, common
+  // PHI instruction in the successor.
+  bool HasUse = !Insts.front()->user_empty();
   for (auto *I : Insts) {
     // These instructions may change or break semantics if moved.
     if (isa<PHINode>(I) || I->isEHPad() || isa<AllocaInst>(I) ||
         I->getType()->isTokenTy())
       return false;
 
     // Conservatively return false if I is an inline-asm instruction. Sinking
     // and merging inline-asm instructions can potentially create arguments
     // that cannot satisfy the inline-asm constraints.
     if (const auto *C = dyn_cast<CallBase>(I))
       if (C->isInlineAsm())
         return false;
 
-    // Everything must have only one use too, apart from stores which
-    // have no uses.
-    if (!isa<StoreInst>(I) && !I->hasOneUse())
+    // Each instruction must have zero or one use.
+    if (HasUse && !I->hasOneUse())
+      return false;
+    if (!HasUse && !I->user_empty())
       return false;
   }
 
   const Instruction *I0 = Insts.front();
   for (auto *I : Insts)
     if (!I->isSameOperationAs(I0))
       return false;
 
-  // All instructions in Insts are known to be the same opcode. If they aren't
-  // stores, check the only user of each is a PHI or in the same block as the
-  // instruction, because if a user is in the same block as an instruction
-  // we're contemplating sinking, it must already be determined to be sinkable.
-  if (!isa<StoreInst>(I0)) {
+  // All instructions in Insts are known to be the same opcode. If they have a
+  // use, check that the only user is a PHI or in the same block as the
+  // instruction, because if a user is in the same block as an instruction we're
+  // contemplating sinking, it must already be determined to be sinkable.
+  if (HasUse) {
     auto *PNUse = dyn_cast<PHINode>(*I0->user_begin());
     auto *Succ = I0->getParent()->getTerminator()->getSuccessor(0);
     if (!all_of(Insts, [&PNUse,&Succ](const Instruction *I) -> bool {
           auto *U = cast<Instruction>(*I->user_begin());
           return (PNUse &&
                   PNUse->getParent() == Succ &&
                   PNUse->getIncomingValueForBlock(I->getParent()) == I) ||
                  U->getParent() == I->getParent();
if (!isa<DbgInfoIntrinsic>(I))
       Insts.push_back(I);
   }
 
   // The only checking we need to do now is that all users of all instructions
   // are the same PHI node. canSinkLastInstruction should have checked this but
   // it is slightly over-aggressive - it gets confused by commutative instructions
   // so double-check it here.
   Instruction *I0 = Insts.front();
-  if (!isa<StoreInst>(I0)) {
+  if (!I0->user_empty()) {
     auto *PNUse = dyn_cast<PHINode>(*I0->user_begin());
     if (!all_of(Insts, [&PNUse](const Instruction *I) -> bool {
           auto *U = cast<Instruction>(*I->user_begin());
           return U == PNUse;
         }))
       return false;
   }
 
if (I != I0) {
       // This is an N-way merge, which will be inefficient if I0 is a CallInst.
       // However, as N-way merge for CallInst is rare, so we use simplified API
       // instead of using complex API for N-way merge.
       I0->applyMergedLocation(I0->getDebugLoc(), I->getDebugLoc());
       combineMetadataForCSE(I0, I, true);
       I0->andIRFlags(I);
     }
 
-  if (!isa<StoreInst>(I0)) {
+  if (!I0->user_empty()) {
     // canSinkLastInstruction checked that all instructions were used by
     // one and only one PHI node. Find that now, RAUW it to our common
     // instruction and nuke it.
-    assert(I0->hasOneUse());
     auto *PN = cast<PHINode>(*I0->user_begin());
     PN->replaceAllUsesWith(I0);
     PN->eraseFromParent();
   }
 
   // Finally nuke all instructions apart from the common instruction.
   for (auto *I : Insts)
     if (I != I0)

llvm/test/CodeGen/AArch64/max-jump-table.ll

 ; RUN: llc %s -O2 -print-machineinstrs -mtriple=aarch64-linux-gnu -jump-table-density=40                        -o /dev/null 2> %t; FileCheck %s --check-prefixes=CHECK,CHECK0  < %t
 ; RUN: llc %s -O2 -print-machineinstrs -mtriple=aarch64-linux-gnu -jump-table-density=40 -max-jump-table-size=4 -o /dev/null 2> %t; FileCheck %s --check-prefixes=CHECK,CHECK4  < %t
 ; RUN: llc %s -O2 -print-machineinstrs -mtriple=aarch64-linux-gnu -jump-table-density=40 -max-jump-table-size=8 -o /dev/null 2> %t; FileCheck %s --check-prefixes=CHECK,CHECK8  < %t
 ; RUN: llc %s -O2 -print-machineinstrs -mtriple=aarch64-linux-gnu -jump-table-density=40 -mcpu=exynos-m1        -o /dev/null 2> %t; FileCheck %s --check-prefixes=CHECK,CHECKM1 < %t
 ; RUN: llc %s -O2 -print-machineinstrs -mtriple=aarch64-linux-gnu -jump-table-density=40 -mcpu=exynos-m3        -o /dev/null 2> %t; FileCheck %s --check-prefixes=CHECK,CHECKM3 < %t
 
-declare void @ext(i32)
+declare void @ext(i32, i32)
 
 define i32 @jt1(i32 %a, i32 %b) {
 entry:
   switch i32 %a, label %return [
     i32 1, label %bb1
     i32 2, label %bb2
     i32 3, label %bb3
     i32 4, label %bb4

 ; CHECK8-SAME: %jump-table.1:
 ; CHECK8-NOT: %jump-table.2:
 ; CHECKM1-NEXT: %jump-table.0:
 ; CHECKM1-SAME: %jump-table.1
 ; CHECKM1-NOT: %jump-table.2:
 ; CHECKM3-NEXT: %jump-table.0:
 ; CHECKM3-NOT: %jump-table.1:
 
-bb1: tail call void @ext(i32 0) br label %return
-bb2: tail call void @ext(i32 2) br label %return
-bb3: tail call void @ext(i32 4) br label %return
-bb4: tail call void @ext(i32 6) br label %return
-bb5: tail call void @ext(i32 8) br label %return
-bb6: tail call void @ext(i32 10) br label %return
-bb7: tail call void @ext(i32 12) br label %return
-bb8: tail call void @ext(i32 14) br label %return
-bb9: tail call void @ext(i32 16) br label %return
-bb10: tail call void @ext(i32 18) br label %return
-bb11: tail call void @ext(i32 20) br label %return
-bb12: tail call void @ext(i32 22) br label %return
-bb13: tail call void @ext(i32 24) br label %return
-bb14: tail call void @ext(i32 26) br label %return
-bb15: tail call void @ext(i32 28) br label %return
-bb16: tail call void @ext(i32 30) br label %return
-bb17: tail call void @ext(i32 32) br label %return
+bb1: tail call void  @ext(i32 1, i32 0) br label %return
+bb2: tail call void  @ext(i32 2, i32 2) br label %return
+bb3: tail call void  @ext(i32 3, i32 4) br label %return
+bb4: tail call void  @ext(i32 4, i32 6) br label %return
+bb5: tail call void  @ext(i32 5, i32 8) br label %return
+bb6: tail call void  @ext(i32 6, i32 10) br label %return
+bb7: tail call void  @ext(i32 7, i32 12) br label %return
+bb8: tail call void  @ext(i32 8, i32 14) br label %return
+bb9: tail call void  @ext(i32 9, i32 16) br label %return
+bb10: tail call void @ext(i32 1, i32 18) br label %return
+bb11: tail call void @ext(i32 2, i32 20) br label %return
+bb12: tail call void @ext(i32 3, i32 22) br label %return
+bb13: tail call void @ext(i32 4, i32 24) br label %return
+bb14: tail call void @ext(i32 5, i32 26) br label %return
+bb15: tail call void @ext(i32 6, i32 28) br label %return
+bb16: tail call void @ext(i32 7, i32 30) br label %return
+bb17: tail call void @ext(i32 8, i32 32) br label %return
 
 return: ret i32 %b
 }
 
 define void @jt2(i32 %x) {
 entry:
   switch i32 %x, label %return [
     i32 1, label %bb1

 ; CHECK8-NEXT: %jump-table.0:  %bb.1 %bb.2 %bb.3 %bb.4{{$}}
 ; CHECK8-NOT: %jump-table.1
 ; CHECKM1-NEXT: %jump-table.0:  %bb.1 %bb.2 %bb.3 %bb.4{{$}}
 ; CHECKM1-NOT: %jump-table.1
 ; CHECKM3-NEXT: %jump-table.0:  %bb.1 %bb.2 %bb.3 %bb.4 %bb.7 %bb.7 %bb.7 %bb.7 %bb.7 %bb.7 %bb.7 %bb.7 %bb.7 %bb.5 %bb.6{{$}}
 ; CHECKM3-NOT: %jump-table.1
 ; CHECK-DAG: End machine code for function jt2.
 
-bb1: tail call void @ext(i32 1) br label %return
-bb2: tail call void @ext(i32 2) br label %return
-bb3: tail call void @ext(i32 3) br label %return
-bb4: tail call void @ext(i32 4) br label %return
-bb5: tail call void @ext(i32 5) br label %return
-bb6: tail call void @ext(i32 6) br label %return
+bb1: tail call void @ext(i32 6, i32 1) br label %return
+bb2: tail call void @ext(i32 5, i32 2) br label %return
+bb3: tail call void @ext(i32 4, i32 3) br label %return
+bb4: tail call void @ext(i32 3, i32 4) br label %return
+bb5: tail call void @ext(i32 2, i32 5) br label %return
+bb6: tail call void @ext(i32 1, i32 6) br label %return
 return: ret void
 }

llvm/test/CodeGen/AArch64/min-jump-table.ll

 ; RUN: llc %s -O2 -print-machineinstrs -mtriple=aarch64-linux-gnu -jump-table-density=40 -min-jump-table-entries=0 -o /dev/null 2> %t; FileCheck %s --check-prefixes=CHECK,CHECK0  < %t
 ; RUN: llc %s -O2 -print-machineinstrs -mtriple=aarch64-linux-gnu -jump-table-density=40 -min-jump-table-entries=4 -o /dev/null 2> %t; FileCheck %s --check-prefixes=CHECK,CHECK4  < %t
 ; RUN: llc %s -O2 -print-machineinstrs -mtriple=aarch64-linux-gnu -jump-table-density=40 -min-jump-table-entries=8 -o /dev/null 2> %t; FileCheck %s --check-prefixes=CHECK,CHECK8  < %t
 
-declare void @ext(i32)
+declare void @ext(i32, i32)
 
 define i32 @jt2(i32 %a, i32 %b) {
 entry:
   switch i32 %a, label %return [
     i32 1, label %bb1
     i32 2, label %bb2
   ]
 ; CHECK-LABEL: function jt2:
 ; CHECK0-NEXT: Jump Tables:
 ; CHECK0-NEXT: %jump-table.0:
 ; CHECK0-NOT: %jump-table.1:
 ; CHECK4-NOT: {{^}}Jump Tables:
 ; CHECK8-NOT: {{^}}Jump Tables:
 
-bb1: tail call void @ext(i32 0) br label %return
-bb2: tail call void @ext(i32 2) br label %return
+bb1: tail call void @ext(i32 1, i32 0) br label %return
+bb2: tail call void @ext(i32 2, i32 2) br label %return
 
 return: ret i32 %b
 }
 
 define i32 @jt4(i32 %a, i32 %b) {
 entry:
   switch i32 %a, label %return [
     i32 1, label %bb1
     i32 2, label %bb2
     i32 3, label %bb3
     i32 4, label %bb4
   ]
 ; CHECK-LABEL: function jt4:
 ; CHECK0-NEXT: Jump Tables:
 ; CHECK0-NEXT: %jump-table.0:
 ; CHECK0-NOT: %jump-table.1:
 ; CHECK4-NEXT: Jump Tables:
 ; CHECK4-NEXT: %jump-table.0:
 ; CHECK4-NOT: %jump-table.1:
 ; CHECK8-NOT: {{^}}Jump Tables:
 
-bb1: tail call void @ext(i32 0) br label %return
-bb2: tail call void @ext(i32 2) br label %return
-bb3: tail call void @ext(i32 4) br label %return
-bb4: tail call void @ext(i32 6) br label %return
+bb1: tail call void @ext(i32 1, i32 0) br label %return
+bb2: tail call void @ext(i32 3, i32 2) br label %return
+bb3: tail call void @ext(i32 4, i32 4) br label %return
+bb4: tail call void @ext(i32 5, i32 6) br label %return
 
 return: ret i32 %b
 }
 
 define i32 @jt8(i32 %a, i32 %b) {
 entry:
   switch i32 %a, label %return [
     i32 1, label %bb1
     i32 2, label %bb2
     i32 3, label %bb3
     i32 4, label %bb4
     i32 5, label %bb5
     i32 6, label %bb6
     i32 7, label %bb7
     i32 8, label %bb8
   ]
 ; CHECK-LABEL: function jt8:
 ; CHECK-NEXT: Jump Tables:
 ; CHECK-NEXT: %jump-table.0:
 ; CHECK-NOT: %jump-table.1:
 
-bb1: tail call void @ext(i32 0) br label %return
-bb2: tail call void @ext(i32 2) br label %return
-bb3: tail call void @ext(i32 4) br label %return
-bb4: tail call void @ext(i32 6) br label %return
-bb5: tail call void @ext(i32 8) br label %return
-bb6: tail call void @ext(i32 10) br label %return
-bb7: tail call void @ext(i32 12) br label %return
-bb8: tail call void @ext(i32 14) br label %return
+bb1: tail call void @ext(i32 1, i32 0) br label %return
+bb2: tail call void @ext(i32 2, i32 2) br label %return
+bb3: tail call void @ext(i32 3, i32 4) br label %return
+bb4: tail call void @ext(i32 4, i32 6) br label %return
+bb5: tail call void @ext(i32 5, i32 8) br label %return
+bb6: tail call void @ext(i32 6, i32 10) br label %return
+bb7: tail call void @ext(i32 7, i32 12) br label %return
+bb8: tail call void @ext(i32 8, i32 14) br label %return
 
 return: ret i32 %b
 }
 

llvm/test/CodeGen/AArch64/win64-jumptable.ll

 ; RUN: llc -o - %s -mtriple=aarch64-windows -aarch64-enable-compress-jump-tables=0 | FileCheck %s
 
 define void @f(i32 %x) {
 entry:
   switch i32 %x, label %sw.epilog [
     i32 0, label %sw.bb
     i32 1, label %sw.bb1
     i32 2, label %sw.bb2
     i32 3, label %sw.bb3
   ]
 
-sw.bb:                                            ; preds = %entry
-  tail call void @g(i32 0) #2
+sw.bb:
+  tail call void @g(i32 0, i32 4)
   br label %sw.epilog
 
-sw.bb1:                                           ; preds = %entry
-  tail call void @g(i32 1) #2
+sw.bb1:
+  tail call void @g(i32 1, i32 5)
   br label %sw.epilog
 
-sw.bb2:                                           ; preds = %entry
-  tail call void @g(i32 2) #2
+sw.bb2:
+  tail call void @g(i32 2, i32 6)
   br label %sw.epilog
 
-sw.bb3:                                           ; preds = %entry
-  tail call void @g(i32 3) #2
+sw.bb3:
+  tail call void @g(i32 3, i32 7)
   br label %sw.epilog
 
-sw.epilog:                                        ; preds = %entry, %sw.bb3, %sw.bb2, %sw.bb1, %sw.bb
-  tail call void @g(i32 10) #2
+sw.epilog:
+  tail call void @g(i32 10, i32 8)
   ret void
 }
 
-declare void @g(i32)
+declare void @g(i32, i32)
 
-; CHECK:    .text
-; CHECK:    f:
-; CHECK:    .seh_proc f
-; CHECK:    b g
-; CHECK-NEXT: .p2align  2
-; CHECK-NEXT: .LJTI0_0:
-; CHECK:    .word .LBB0_2-.LJTI0_0
-; CHECK:    .word .LBB0_3-.LJTI0_0
-; CHECK:    .word .LBB0_4-.LJTI0_0
-; CHECK:    .word .LBB0_5-.LJTI0_0
-; CHECK:    .section  .xdata,"dr"
-; CHECK:    .seh_handlerdata
-; CHECK:    .text
-; CHECK:    .seh_endproc
+; CHECK:    .text
+; CHECK:    f:
+; CHECK:    .seh_proc f
+; CHECK:    b g
+; CHECK-NEXT: .p2align  2
+; CHECK-NEXT: .LJTI0_0:
+; CHECK:    .word .LBB0_2-.LJTI0_0
+; CHECK:    .word .LBB0_3-.LJTI0_0
+; CHECK:    .word .LBB0_4-.LJTI0_0
+; CHECK:    .word .LBB0_5-.LJTI0_0
+; CHECK:    .section  .xdata,"dr"
+; CHECK:    .seh_handlerdata
+; CHECK:    .text
+; CHECK:    .seh_endproc

llvm/test/CodeGen/ARM/cmpxchg-idioms.ll

 
 ; CHECK: ldrex [[LOADED]], [r0]
 ; CHECK: cmp [[LOADED]], r1
 ; CHECK: beq [[LOOP]]
 
 ; CHECK: [[FAILED]]:
 ; CHECK-NOT: cmp {{r[0-9]+}}, {{r[0-9]+}}
 ; CHECK: clrex
-; CHECK: dmb ish
 ; CHECK: movs r0, #0
+; CHECK: dmb ish
 ; CHECK: bx lr
 
 ; CHECK: [[SUCCESS]]:
 ; CHECK-NOT: cmp {{r[0-9]+}}, {{r[0-9]+}}
-; CHECK: dmb ish
 ; CHECK: movs r0, #1
+; CHECK: dmb ish
 ; CHECK: bx lr
 
   %pair = cmpxchg i32* %p, i32 %oldval, i32 %newval seq_cst seq_cst
   %success = extractvalue { i32, i1 } %pair, 1
   %conv = zext i1 %success to i32
   ret i32 %conv
 }
 

llvm/test/Transforms/SimplifyCFG/sink-common-code.ll

if.end:
   ret i32 1
 }
 
 ; CHECK-LABEL: @test_insertvalue
 ; CHECK: select
 ; CHECK: insertvalue
 ; CHECK-NOT: insertvalue
 
+
+declare void @baz(i32)
+
+define void @test_sink_void_calls(i32 %x) {
+entry:
+  switch i32 %x, label %default [
+    i32 0, label %bb0
+    i32 1, label %bb1
+    i32 2, label %bb2
+    i32 3, label %bb3
+    i32 4, label %bb4
+  ]
+bb0:
+  call void @baz(i32 12)
+  br label %return
+bb1:
+  call void @baz(i32 34)
+  br label %return
+bb2:
+  call void @baz(i32 56)
+  br label %return
+bb3:
+  call void @baz(i32 78)
+  br label %return
+bb4:
+  call void @baz(i32 90)
+  br label %return
+default:
+  unreachable
+return:
+  ret void
+
+; Check that the calls get sunk to the return block.
+; We would previously not sink calls without uses, see PR41259.
+; CHECK-LABEL: @test_sink_void_calls
+; CHECK-NOT: call
+; CHECK-LABEL: return:
+; CHECK: phi
+; CHECK: call
+; CHECK-NOT: call
+; CHECK: ret
+}
+
+
 ; CHECK: ![[$TBAA]] = !{![[TYPE:[0-9]]], ![[TYPE]], i64 0}
 ; CHECK: ![[TYPE]] = !{!"float", ![[TEXT:[0-9]]]}
 ; CHECK: ![[TEXT]] = !{!"an example type tree"}