[utils] InlineFunction: fix for debug info affecting optimizations

[yechunliang]

Summary

Debug info affects output from "opt -inline", InlineFunction could not handle the llvm.dbg.value when it exist between alloca instructions, scanning the block of allocas will get wrong result if llvm.dbg.value instr exist. Skip dbg instr while allocas scanning.

Fix the issue: https://bugs.llvm.org/show_bug.cgi?id=43291k

[jmorse]

Looks good, one concern about whether too many debug instructions may get moved written inline

llvm/lib/Transforms/Utils/InlineFunction.cpp

1842–1843

Is there a possibility of an unrelated debug instruction being skipped here, and becoming part of the slice moved by lines 1847-1857? Moving dbg.values of arguments to the start of the caller may create a debug use-before-def situation, there could be other problem scenarios too.

Using a debug-instruction filtering iterator (like here [0]) might just do-the-right-thing, I don't know whether feeding one to splice would behave correctly though.

[0] https://github.com/llvm/llvm-project/blob/fdaa74217420729140f1786ea037ac445a724c8e/llvm/lib/Transforms/Utils/SimplifyCFG.cpp#L2592

llvm/test/Transforms/Inline/inline-with-debuginfo.ll

5–6

The bug report number would be nice too

58–60

We generally delete function attributes if they're not necessary

[bjope]

I do not understand how this helps. The code is written in a way that it skips any instruction, but moves contigous blocks of allocas in one splice (not sure exactly why, is that really faster?). Maybe the difference is that the check for AI->useEmpty() only is done for the first alloca in a sequence of alloca instructions? Or can't we just remove the loop at line 1847 (only moving one alloca at a time).

[aprantl]

llvm/lib/Transforms/Utils/InlineFunction.cpp

1842–1843

Don't we have an iterator that automatically skips debug intrinsics?

[jdoerfert]

llvm/lib/Transforms/Utils/InlineFunction.cpp

1862

Don't we need to have similar logic here? What happens if there are two allocas, then the dbg intrinsic, then another one?

[bjope]

In D68633#1699421, @bjope wrote:

I do not understand how this helps. The code is written in a way that it skips any instruction, but moves contigous blocks of allocas in one splice (not sure exactly why, is that really faster?). Maybe the difference is that the check for AI->useEmpty() only is done for the first alloca in a sequence of alloca instructions? Or can't we just remove the loop at line 1847 (only moving one alloca at a time).

The patch description really needs to be updated. Afaict the old code has been doing "Skip dbg instr while allocas scanning.", but with this patch you in some sense start to scan for both alloca instructions _and_ dbg intrinsics. And then some dbg intrinsics will be part of the splice.
As Johannes mentioned this is incomplete (since not all dbg intrinsics are considered, only those appearing after the first alloca in for each lap in the outer for loop).
Besides, inlining decisions should not be impacted by if we move the dbg intrinsics or not, right? That is why I think this fix isn't solving the problem seen in the bugzilla ticket. It only hides the actual problem (given the reduced reproducer).

[aprantl]

In D68633#1700966, @bjope wrote:

Besides, inlining decisions should not be impacted by if we move the dbg intrinsics or not, right?

Correct. clang -g | strip and clang should produce identical output.

[yechunliang]

[inline] skip dbg info when scan allocas

Debug instruction will break the next alloca scanning, the alloca instruction next to debug instruction will fail to insert to the caller function. The debug instructions should be skipped when next allocas scanning.

Fix the issue: https://bugs.llvm.org/show_bug.cgi?id=43291

[aprantl]

llvm/lib/Transforms/Utils/InlineFunction.cpp

1842–1843

Please use BasicBlock:: instructionsWithoutDebug () instead of rolling your own.

https://llvm.org/doxygen/classllvm_1_1BasicBlock.html#aa696c5026c1241f4dd097f3558a43a47

1860

llvm style would be to reverse the condition: break first, then unconditionally execute the code.

[bjope]

I'm still confused. IMO moving or not moving dbg instructions is a different question (not being discussed here). Still no explanation why result differs depending on if we move dbg instructuons or not. And this patch now blindly moves some dbg instructions, regardless if they are related to the allocas or not. Consider an instruction sequence like this:

alloca
bitcast
dbg.declare
bitcast
alloca
bitcast
dbg.value

The scanning for allocas will find the two alloca instructions and call splice twice, only moving the alloca instructions, right?

The input IR could probably have looked like this instead:

alloca
dbg.declare
bitcast
bitcast
alloca
dbg.value
bitcast

and then suddenly (with this patch) we start to move the dbg intrinsics (but we still do not move the bitcasts, nor dbg intrinsics that do not have an alloca as predecessor).

I simply do not see the logic with this change.

[yechunliang]

In D68633#1699421, @bjope wrote:

The code is written in a way that it skips any instruction, but moves contigous blocks of allocas in one splice (not sure exactly why, is that really faster?).

I also could not understand why continue to scan allocas block after first none use_empty alloca instruction, here is the first commit has some reason: https://github.com/llvm/llvm-project/commit/6f8865bf9

Maybe the difference is that the check for AI->useEmpty() only is done for the first alloca in a sequence of alloca instructions? Or can't we just remove the loop at line 1847 (only moving one alloca at a time).

with this example test case, second alloca is use_empty, and will insert to caller together with first alloca (!use_empty). But if there is dbg instruction between first alloca and second alloca instruction. the continue scan will break,
then with the debug instruction, the program will goto the front for() loop, and handle the second alloca as use_empty (because it has no use list like "xxx.sroa_cast = bitcast %rec1198* %volatileloadslot to i8*") and eraseFromParent.
this is difference as no-dbg inline will not erase second alloca instruction.

llvm/lib/Transforms/Utils/InlineFunction.cpp

1842–1843

Is there a possibility of an unrelated debug instruction being skipped here,

By default, the debug instruction between allocas will insert to caller together with block of allocas, I just keep the default behavier. Not sure if we need to remove the dbg instr when inline to the caller.

Using a debug-instruction filtering iterator (like here [0]) might just do-the-right-thing,

I could not found the way to use debug-instruction filtering like instructionsWithoutDebug(llvm::Instruction) to handle BasicBlock::iterator. the format not match, so I used DbgInfoInstrinsic for simple usage.

1862

thanks for the comments, this is a good case, I have updated code and testcase to handle this.

[yechunliang]

Update patch:

1. Use BasicBlock::iterator skipDebugIntrinsics instead of rolling directly. The recommend API BasicBlock:: instructionsWithoutDebug() looks not very suitable to handle llvm::Instruction in this code.
2. follow llvm style, condition: break first, then unconditionally execute the code

[bjope]

In D68633#1705291, @yechunliang wrote:

In D68633#1699421, @bjope wrote:

The code is written in a way that it skips any instruction, but moves contigous blocks of allocas in one splice (not sure exactly why, is that really faster?).

I also could not understand why continue to scan allocas block after first none use_empty alloca instruction, here is the first commit has some reason: https://github.com/llvm/llvm-project/commit/6f8865bf9

Maybe the difference is that the check for AI->useEmpty() only is done for the first alloca in a sequence of alloca instructions? Or can't we just remove the loop at line 1847 (only moving one alloca at a time).

with this example test case, second alloca is use_empty, and will insert to caller together with first alloca (!use_empty). But if there is dbg instruction between first alloca and second alloca instruction. the continue scan will break,
then with the debug instruction, the program will goto the front for() loop, and handle the second alloca as use_empty (because it has no use list like "xxx.sroa_cast = bitcast %rec1198* %volatileloadslot to i8*") and eraseFromParent.
this is difference as no-dbg inline will not erase second alloca instruction.

So the root cause is rather that we treat an alloca being immediately preceeded by another alloca differrently from the case when it is preceeded by another kind of instruction. This happens also when having other instructions in between, and is not specific to dbg intrinsics (could be interesting to add a test case where you replace the dbg intrinsics by something else).

So I think that the solution might be based on one of these ideas:

1. Remove the check for use_empty in the outer loop.
2. Add a check for !use_empty in the inner loop.
3. Remove the inner loop (i.e only splice one alloca at a time).

Alternative 3 would be the simplest.

If there really is a speedup on doing fewer splices, then alternative 2 still moves consequtive !use_empty allocas in batches. The idea with alternative 2 is to split batches on allocas that has no uses (as they are handled in the outer loop).

Alternative 1 might work assuming that allocas with no uses are cleaned up somewhere else. But I think this alternative is the least interesting one.

[yechunliang]

So the root cause is rather that we treat an alloca being immediately preceeded by another alloca differrently from the case when it is preceeded by another kind of instruction. This happens also when having other instructions in between, and is not specific to dbg intrinsics (could be interesting to add a test case where you replace the dbg intrinsics by something else).

Yes I think so, if the other instruction is not dbg instr which exist between two allocas, the InlineFunction with and without "-strip-debug" will make the same behavior, that should both erase second use_empty alloca. This patch is to fix the issue that debug instr impact InlineFunction generate different output.

So I think that the solution might be based on one of these ideas:

1. Remove the check for use_empty in the outer loop.
2. Add a check for !use_empty in the inner loop.
3. Remove the inner loop (i.e only splice one alloca at a time).

These good ideas should be talking about the design change of alloca inline or improvement of splice.
Read from the code, I think about the alloca inline behavior like this: First detect one !use_empty alloca, if next immediate instructions are allocas, even they are use_empty, they will all added one after one and move to caller together with first alloca. if other instruction (whatever dbg or others instrs) exist between allocas, the next alloca will check if is use_empty or not, if is use_empty then erase. Does this behavior correct, or could be improve? I don't know much about alloca inline. but seems the code run many years with this design.

[aprantl]

llvm/lib/Transforms/Utils/InlineFunction.cpp

1854

Does this work when I == E here?

[bjope]

In D68633#1705697, @yechunliang wrote:

So the root cause is rather that we treat an alloca being immediately preceeded by another alloca differrently from the case when it is preceeded by another kind of instruction. This happens also when having other instructions in between, and is not specific to dbg intrinsics (could be interesting to add a test case where you replace the dbg intrinsics by something else).

Yes I think so, if the other instruction is not dbg instr which exist between two allocas, the InlineFunction with and without "-strip-debug" will make the same behavior, that should both erase second use_empty alloca. This patch is to fix the issue that debug instr impact InlineFunction generate different output.

So I think that the solution might be based on one of these ideas:

1. Remove the check for use_empty in the outer loop.
2. Add a check for !use_empty in the inner loop.
3. Remove the inner loop (i.e only splice one alloca at a time).

These good ideas should be talking about the design change of alloca inline or improvement of splice.
Read from the code, I think about the alloca inline behavior like this: First detect one !use_empty alloca, if next immediate instructions are allocas, even they are use_empty, they will all added one after one and move to caller together with first alloca. if other instruction (whatever dbg or others instrs) exist between allocas, the next alloca will check if is use_empty or not, if is use_empty then erase. Does this behavior correct, or could be improve? I don't know much about alloca inline. but seems the code run many years with this design.

I'm no expert on this part of the code either. But there is no reasonable logic in handling allocas differently depending on the existence of other allocas here afaict. It looks like it has been like that for over 10 years, but I doubt that it justifies adding yet another level of illogical handling here. This time handling dbg intrinsics differently depending on the existance of, possibly unrelated, alloca instructions. It would just make this an even bigger mess. Would be much better if we could fix what seems to have been a bug(?) for over a decade (which also would solve the debug invariance problem).

(Maybe you'll need another set of reviewers considering that the fix would impact the alloca inlining slightly, rather than just aiming at dbg intrinsics?)

[yechunliang]

! In D68633#1699421, @bjope wrote:
So I think that the solution might be based on one of these ideas:

1. Remove the check for use_empty in the outer loop.
2. Add a check for !use_empty in the inner loop.
3. Remove the inner loop (i.e only splice one alloca at a time).
   
   Alternative 3 would be the simplest. If there really is a speedup on doing fewer splices, then alternative 2 still moves consequtive !use_empty allocas in batches. The idea with alternative 2 is to split batches on allocas that has no uses (as they are handled in the outer loop). Alternative 1 might work assuming that allocas with no uses are cleaned up somewhere else. But I think this alternative is the least interesting one.

I prefer to adopt alternative 2. I think use_empty alloca (the dead alloca) should also be erased in inner loop.

[yechunliang]

Rethink about this issue and the root cause should be caused by use_empty. Just resubmitted the patch with "[InlineFunction] Erase use_empty allocas when inline".

Updated patch description:

[InlineFunction] Erase use_empty allocas when inline  
- When continuely scan block of allocas, in the inner loop, there is lack of use_empty check, this will cause use_empty alloca instruction next to previous alloca insert to the caller. This will make different output when there is debug instruction between two alloca instructions (with/without --with-strip). This patch add use_empty() check in the alloca scanning inner loop. Exit the inner loop when find next alloca instruction is use_empty and handle to earse it in the outer loop.
  a) callee:
    %1 = alloca (used)
    dbg
    %2 = alloca (use empty)
    dbg
    %3 = alloca3 (used)

  b) inline caller expection: (the use_empty %2 be removed)
    %1 = alloca (used)
    dbg
    dbg
    %3 = alloca3 (used)
- Also skip debug instruction in the inner loop for continue alloca scanning. 
Fix the issue: https://bugs.llvm.org/show_bug.cgi?id=43291

[yechunliang]

fix typo of patch description

[vsk]

Hey @yechunliang, thanks for working on this.

This part of the inliner looks like it has two issues: 1) it's not fully aware of debug instructions, and 2) it erroneously extends the lifetimes of inlined variables. The current iteration of your patch might address the first issue, but it's not DRY, and it doesn't solve the second.

Here are a few suggestions.

• Please split out the logic for moving callee allocas into a helper function. This should simplify review.
• Use the filtering iterator to skip debug instructions. I understand that you had some trouble with this. Here's a patch based on an older version of your diff:

inlinefunc.diff2 KBDownload

• Moving the dbg.declares along with the callee's allocas to the entry block erroneously extends the lifetimes of all those allocas to the whole function. This makes frame inspection in the debugger really confusing. To fix this, I think you should just not move the dbg.declares. The easiest way to do that is to stop batch-splicing, as @bjope pointed out.

[bjope]

In D68633#1709729, @vsk wrote:

Hey @yechunliang, thanks for working on this.

This part of the inliner looks like it has two issues: 1) it's not fully aware of debug instructions, and 2) it erroneously extends the lifetimes of inlined variables. The current iteration of your patch might address the first issue, but it's not DRY, and it doesn't solve the second.

Well, this part of the code is actually aware of dbg.declares (associated with the allocas), and moves those separately. This is done after the loop. And I guess that is (at least one reason to) why we save information about moves allocas in IFI.StaticAllocas.
Not sure if that is a bad thing to do or not, but that is probably a different problem. I think the initial goal here was to get rid of the debug invariance, i.e. that allocas could either be moved or removed depending on the presence of debug info.

My suggested solution to that is to handle all allocas the same (not treating two allocas in a row differently from two allocas separated by any other instruction). This makes this part of the code less sensitive to the order of instructions in the input. As a side effect (of such an improvement) the debug invariance problem is expected to go away.

Here are a few suggestions.

• Please split out the logic for moving callee allocas into a helper function. This should simplify review.
• Use the filtering iterator to skip debug instructions. I understand that you had some trouble with this. Here's a patch based on an older version of your diff:

inlinefunc.diff2 KBDownload

• Moving the dbg.declares along with the callee's allocas to the entry block erroneously extends the lifetimes of all those allocas to the whole function. This makes frame inspection in the debugger really confusing. To fix this, I think you should just not move the dbg.declares. The easiest way to do that is to stop batch-splicing, as @bjope pointed out.

I don't really see a reason for splitting this into a helper function. Nor starting to use a filtering iterator. My opinion is that the loop only should consider alloca instruction (just like it is today on trunk). But either the inner loop should be removed (only moving one alloca at a time), or if we still want to move sequences of alloca instructions, then the checks to determine if an alloca should be moved or not should be the same in the inner loop as in the outer loop. So the inner loop could simply look like this:

while (isa<AllocaInst>(I) &&
       !cast<AllocaInst>(I)->use_empty() &&
       allocaWouldBeStaticInEntry(cast<AllocaInst>(I))) {
  IFI.StaticAllocas.push_back(cast<AllocaInst>(I));
  ++I;
}

If we keep the inner loop the conditions for keeping/moving/removing an alloca is duplicated. So it would be much simpler just to stop doing batch moves.

[vsk]

My suggested solution to that is to handle all allocas the same (not treating two allocas in a row differently from two allocas separated by any other instruction). This makes this part of the code less sensitive to the order of instructions in the input. As a side effect (of such an improvement) the debug invariance problem is expected to go away.

Yes, I agree with this. There's no need to use a filtering iterator with this approach: you need an isa<AllocaInst> check either way. We can consider the dbg.declare movement separately, sure.

[yechunliang]

@bjope, @vsk: Thanks very much for the comments, really help me.

I have verified below two options, both could work, but don't know which is better.

Option1: Just add !use_empty check in the inner loop. if debug exist, alloca will be handled separately and move one alloca to the caller each time,
if no debug, the alloca will be handled in sequence and move all (!use_empty) allocas to the caller at one time. (here is the inline speed up improvement, don't know there is the case is frequently used and how to measure the performance?)
the process is a little different but the optimization results are same. Does this acceptable?

Option2: Remove inner loop, all alloca will be handled once, splice immediately for each alloca, the benefits are no duplicate checking code, no debug impact.
but it may loss inline speed up improvement for blocks of allocas.

[yechunliang]

just added use_empty check in the inner loop, this will be the smallest code change for issue fixing.

[InlineFunction] skip use_empty allocas when inline

Add use_empty check in alloca inner loop scanning, if the alloca is use_empty, do not move it to the entry block of the caller, stop scanning and goto splice immediately.

the behavior should be like this:
  a) the callee:
    %a = alloca (is !use_empty)
    %b = alloca (is use_empty)
    %c = alloca (is !use_empty)

  b) the caller after inline: (instr %b is skipped)
    %a = alloca (is !use_empty)
    %c = alloca (is !use_empty)

Fix the issue: https://bugs.llvm.org/show_bug.cgi?id=43291

[bjope]

Thanks! I like this solution.

Moving focus to the test case. I've added a couple of suggestions for cleanup.

llvm/test/Transforms/Inline/inline-skip-use-empty-alloca.ll

31 ↗

(On Diff #225583)

This can basically match any line containing the letter g. Is it possible to make a more complete match?
I also suggest to rename the functions here to something like @foo and @bar instead of @f and @g to get something that is easier to distinguish.

43 ↗

(On Diff #225583)

This declaration can be removed (same goes for the lifetime.end).

One trick is to do some cleanup of the test case by using opt -S -strip-dead-prototypes -strip-dead-debug-info to both strip away dead prototypes as well as reducing the amount of unused metadata. Just notice that you have to add back the CHECK/RUN lines etc manually afterwards.

[yechunliang]

update test case:

1. using function name @foo and @bar instead of @f and @g for more complete match

2.cleanup test case with "-strip-dead-prototypes -strip-dead-debug-info"

Thank you @bjope for comments.

[bjope]

Thanks for the patience with all my remarks, turning this around completely compared to the original patch.

LGTM!

[bjope]

Not sure why this isn't in "Accepted" state. I know @aprantl and @vsk asked for a new revision on an earlier diff. So is it perhaps because not all comments have been marked as "Done"?

@yechunliang: Let me know if you need help committing this (not sure if you got commit permissions). I noticed some earlier patch that has been accepted by not yet committed as well (D66467).

[yechunliang]

@bjope thanks for help, to be honest, I don't know the process or execution of commit, I thought I have no commit permission right now.

[bjope]

In D68633#1723326, @yechunliang wrote:

@bjope thanks for help, to be honest, I don't know the process or execution of commit, I thought I have no commit permission right now.

The procedure should be described here:

http://llvm.org/docs/Contributing.html#how-to-submit-a-patch

It says

This cycle continues until all requests and comments have been addressed and a reviewer accepts the patch with a Looks good to me or LGTM. Once that is done the change can be committed. If you do not have commit access, please let people know during the review and someone should commit it on your behalf.

So it is perfectly OK to ask the reviewers to submit it for you.

When your contribution increases, you can obtain commit access (to both push your own patches and also maybe to help new contributers). That should be covered by

http://llvm.org/docs/DeveloperPolicy.html#obtaining-commit-access

(not sure if the process will change due to the ongoing transfer from SVN->GitHub).

I haven't pushed directly to GitHub myself yet. I'll try to commit this patch for you, also verifying that my commit access still works.

[yechunliang]

@bjope,@jmorse, @aprantl, @jdoerfert, @vsk thank you all for kind and patient help on code review and giving me many supports and guidelines, I'm glad this(my first) patch be accepted and merged on llvm-project. Really thank you.

llvm/lib/Transforms/Utils/InlineFunction.cpp

for (BasicBlock::iterator I = FirstNewBlock->begin(),
       }
 
       if (!allocaWouldBeStaticInEntry(AI))
         continue;
 
       // Keep track of the static allocas that we inline into the caller.
       IFI.StaticAllocas.push_back(AI);
 
       // Scan for the block of allocas that we can move over, and move them
       // all at once.
-      while (isa<AllocaInst>(I) &&
+      while (I != E) {
+        // Debug instruction will break the next alloca scanning, the alloca
+        // instruction next to debug instruction will fail to insert to the
+        // caller function. The debug instructions should be skipped when
+        // next allocas scanning.
+        if (isa<DbgInfoIntrinsic>(I)) {
+          I++;
+          continue;
+        }
+        // Scan the next instruction, if the next instr is AllocaInst,
+        // continue to scan, otherwise, exit the scanning.
+        if (isa<AllocaInst>(I) &&
                allocaWouldBeStaticInEntry(cast<AllocaInst>(I))) {
           IFI.StaticAllocas.push_back(cast<AllocaInst>(I));
           ++I;
+        } else {
+          break;
+        }
       }
 
       // Transfer all of the allocas over in a block.  Using splice means
       // that the instructions aren't removed from the symbol table, then
       // reinserted.
       Caller->getEntryBlock().getInstList().splice(
           InsertPoint, FirstNewBlock->getInstList(), AI->getIterator(), I);
     }
     // Move any dbg.declares describing the allocas into the entry basic block.

llvm/test/Transforms/Inline/inline-with-debuginfo.ll

+; RUN: opt < %s -S -inline | FileCheck %s
+; RUN: opt < %s -S -strip-debug -inline | FileCheck %s
+
+; https://bugs.llvm.org/show_bug.cgi?id=43291
+; The purpose of this test is to check that debug info doesn't influence
+; inlining decisions.
+
+%rec1198 = type { i32, i32 }
+
+define void @f(i16 %k.4.par) !dbg !23 {
+  %volatileloadslot = alloca %rec1198
+  call void @llvm.dbg.value(metadata i16 %k.4.par, metadata !30, metadata !DIExpression()), !dbg !31
+  %l.6 = alloca [3 x i32]
+  call void @llvm.dbg.value(metadata i16 %k.4.par, metadata !30, metadata !DIExpression()), !dbg !31
+  %tmp = alloca [3 x i32]
+  %volatileloadslot.0..sroa_cast = bitcast %rec1198* %volatileloadslot to i8*, !dbg !32
+  call void @llvm.lifetime.start.p0i8(i64 4, i8* %volatileloadslot.0..sroa_cast)
+  %volatileloadslot.0..sroa_cast1 = bitcast %rec1198* %volatileloadslot to i8*
+  call void @llvm.lifetime.end.p0i8(i64 4, i8* %volatileloadslot.0..sroa_cast1)
+  %_tmp23 = icmp ne i16 %k.4.par, 0
+  br i1 %_tmp23, label %bb1, label %bb2
+
+bb1:                                              ; preds = %0
+  %_tmp28 = getelementptr [3 x i32], [3 x i32]* %l.6, i16 0, i64 0
+  store i32 0, i32* %_tmp28
+  br label %bb2
+
+bb2:                                              ; preds = %bb1, %0
+  ret void
+}
+
+define i16 @g() !dbg !33 {
+  ; CHECK-LABEL: g
+  ; CHECK: %l.6.i = alloca [3 x i32]
+  ; CHECK: %tmp.i = alloca [3 x i32]
+  ; CHECK-NEXT: %1 = bitcast [3 x i32]* %l.6.i to i8*
+  ; CHECK-NEXT: call void @llvm.lifetime.start.p0i8(i64 12, i8* %1)
+  ; CHECK-NEXT: %2 = bitcast [3 x i32]* %tmp.i to i8*
+  ; CHECK-NEXT: call void @llvm.lifetime.start.p0i8(i64 12, i8* %2)
+
+  ; CHECK: call void @llvm.lifetime.end.p0i8(i64 4, i8* %volatileloadslot.0..sroa_cast1.i)
+  ; CHECK-NEXT: %3 = bitcast [3 x i32]* %l.6.i to i8*
+  ; CHECK-NEXT: call void @llvm.lifetime.end.p0i8(i64 12, i8* %3)
+  ; CHECK-NEXT: %4 = bitcast [3 x i32]* %tmp.i to i8*
+  ; CHECK-NEXT: call void @llvm.lifetime.end.p0i8(i64 12, i8* %4)
+  call void @f(i16 0), !dbg !36
+  br label %bb1
+
+bb1:                                              ; preds = %0
+  ret i16 0
+}
+
+; Function Attrs: argmemonly nounwind
+declare void @llvm.lifetime.start.p0i8(i64, i8* nocapture)
+
+; Function Attrs: argmemonly nounwind
+declare void @llvm.lifetime.end.p0i8(i64, i8* nocapture)
+
+; Function Attrs: nounwind readnone speculatable
+declare void @llvm.dbg.value(metadata, metadata, metadata)
+
+!llvm.dbg.cu = !{!0}
+!llvm.module.flags = !{!20, !21}
+!llvm.ident = !{!22}
+
+!0 = distinct !DICompileUnit(language: DW_LANG_C, file: !1, producer: "Foo", isOptimized: false, runtimeVersion: 0, emissionKind: FullDebug, enums: !2, retainedTypes: !2, globals: !3)
+!1 = !DIFile(filename: "foo2.c", directory: "/tmp")
+!2 = !{}
+!3 = !{!4, !18}
+!4 = !DIGlobalVariableExpression(var: !5, expr: !DIExpression())
+!5 = !DIGlobalVariable(name: "c", scope: null, file: !1, line: 5, type: !6, isLocal: false, isDefinition: true)
+!6 = !DIDerivedType(tag: DW_TAG_volatile_type, baseType: !7)
+!7 = !DICompositeType(tag: DW_TAG_structure_type, file: !1, line: 2, size: 64, elements: !8)
+!8 = !{!9, !14}
+!9 = !DIDerivedType(tag: DW_TAG_member, name: "a", scope: !7, file: !1, line: 3, baseType: !10, size: 32)
+!10 = !DIDerivedType(tag: DW_TAG_typedef, name: "int32_t", file: !11, line: 74, baseType: !12)
+!11 = !DIFile(filename: "stdint.h", directory: "/tmp")
+!12 = !DIDerivedType(tag: DW_TAG_typedef, name: "__i32_t", file: !1, baseType: !13)
+!13 = !DIBasicType(name: "signed long", size: 32, encoding: DW_ATE_signed)
+!14 = !DIDerivedType(tag: DW_TAG_member, name: "b", scope: !7, file: !1, line: 4, baseType: !15, size: 32, offset: 32)
+!15 = !DIDerivedType(tag: DW_TAG_typedef, name: "uint32_t", file: !11, line: 75, baseType: !16)
+!16 = !DIDerivedType(tag: DW_TAG_typedef, name: "__u32_t", file: !1, baseType: !17)
+!17 = !DIBasicType(name: "unsigned long", size: 32, encoding: DW_ATE_unsigned)
+!18 = !DIGlobalVariableExpression(var: !19, expr: !DIExpression())
+!19 = !DIGlobalVariable(name: "d", scope: null, file: !1, line: 5, type: !6, isLocal: false, isDefinition: true)
+!20 = !{i32 2, !"Dwarf Version", i32 4}
+!21 = !{i32 2, !"Debug Info Version", i32 3}
+!22 = !{!"Foo"}
+!23 = distinct !DISubprogram(name: "f", scope: !1, file: !1, line: 17, type: !24, scopeLine: 17, spFlags: DISPFlagDefinition, unit: !0, retainedNodes: !2)
+!24 = !DISubroutineType(types: !25)
+!25 = !{!26, !29}
+!26 = !DIDerivedType(tag: DW_TAG_typedef, name: "int64_t", file: !11, line: 76, baseType: !27)
+!27 = !DIDerivedType(tag: DW_TAG_typedef, name: "__i64_t", file: !1, baseType: !28)
+!28 = !DIBasicType(name: "signed long long", size: 64, encoding: DW_ATE_signed)
+!29 = !DIBasicType(name: "int", size: 16, encoding: DW_ATE_signed)
+!30 = !DILocalVariable(name: "k", arg: 1, scope: !23, file: !1, line: 17, type: !29)
+!31 = !DILocation(line: 0, scope: !23)
+!32 = !DILocation(line: 19, column: 3, scope: !23)
+!33 = distinct !DISubprogram(name: "g", scope: !1, file: !1, line: 8, type: !34, scopeLine: 8, spFlags: DISPFlagDefinition, unit: !0, retainedNodes: !2)
+!34 = !DISubroutineType(types: !35)
+!35 = !{!29}
+!36 = !DILocation(line: 8, column: 7, scope: !33)