[DebugInfo][FastISel] Prevent using debug location from previous block for local values

[sdmitrouk]

Summary

As FastISel groups local values at the top of each block or after call
instructions and doesn't attach any debug location to them (it's
intentionally cleared to prevent jumping back and forth in debuggers),
the following situation is possible:

BB#0:
    .loc 1 2 3
    call ...
    <constant load>
    .loc 1 5 6
    ...

BB#1:
    <constant load>
    .loc 1 3 4
    ...

Here <constant load> in both cases "accidentally" gets wrong debug location
from the preceding set of instructions, which is wrong.

This patch adds basic block post-processing for FastISel, which will look for
first instruction with non-null debug location and assign the location to first
local value (if one exists), producing the following:

BB#0:
    .loc 1 2 3
    call ...
    .loc 1 5 6
    <constant load>
    ...

BB#1:
    .loc 1 3 4
    <constant load>
    .loc 1 3 4
    ...

[probinson]

Does this handle the case where there is a call in the middle of the block? There is a special case for the local value map at that point, IIRC.
What happens when FastISel decides it can't finish selection for the block, and bails out to regular ISel?

[sdmitrouk]

In D9887#175863, @probinson wrote:

Does this handle the case where there is a call in the middle of the block? There is a special case for the local value map at that point, IIRC.

Didn't try that, will do. This will need to account for calls of flushLocalValueMap, I thought it's used differently. Current version uses MBB->begin() which and probably won't work as expected. Thanks.

In D9887#175863, @probinson wrote:

What happens when FastISel decides it can't finish selection for the block, and bails out to regular ISel?

Regular ISel already produces correct locations (hence this change uses same test as regular ISel). Not sure if there are some complicated cases which will lead to wrong results.

[sdmitrouk]

Thanks to Fred I see that this is basically the same as an old patch (http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20120917/151433.html) related to the bug of the same age (https://llvm.org/bugs/show_bug.cgi?id=14501), which was unfortunately rejected... Still pulled in Pauls nice test case and added missing changes here. I would prefer to have some kind of fix rather than have obviously wrong locations (provided that we don't make anything worse that it is at the moment).

[sdmitrouk]

Ping.

[sdmitrouk]

Ping.

[sdmitrouk]

Ping.

[dblaikie]

Some comments - and it'd still be good to have Alexey take a look and see if this is likely to address some of the issues in line table fidelity he knows about.

I know it won't address them all - especially when inlining within a single basic block causes the same fallthrough-like line table behavior, but at least across basic block this should help tidy things up & avoid any dependence on block ordering.

lib/CodeGen/SelectionDAG/FastISel.cpp

136

I don't see anything EH related in your test cases - is this exercised/verified? (perhaps without this existing tests regress? I'm not sure)

142

Could use std::find_if here, if you like.

test/DebugInfo/X86/dbg-line-fast-isel.ll

11

Do the three blocks in this function all test interesting parts of the patch? Or could we use two? If they're all interesting it might be worth a comment to explain how/why.

Do these test functions need non-void returns, or could they be simplified to return void?

(does the callme function need a non-void return too? Does it need a parameter? (I assume it needs the parameter for some reason))

[sdmitrouk]

Some comments

Thanks, they are addressed in the next revision.

it'd still be good to have Alexey take a look and see if this is likely to address some of the issues in line table fidelity he knows about.

I'll subscribe him, maybe he'll find time to take a look.

lib/CodeGen/SelectionDAG/FastISel.cpp

136

I tried to repeat search of insert position performed by FastISel::recomputeInsertPt(). Now tried to get misplaced debug locations without this change and couldn't, so removed it.

142

Right, that's better.

test/DebugInfo/X86/dbg-line-fast-isel.ll

11

Do the three blocks in this function all test interesting parts of the patch? Or could we use two? If they're all interesting it might be worth a comment to explain how/why.

Not really, the first call isn't actually checked for anything, that check is in the second function.

Do these test functions need non-void returns, or could they be simplified to return void?

The first one does, because there is a check that 0 from return 0 has correct debug location.

does the callme function need a non-void return too?

It's not necessary, will be changed.

Does it need a parameter? (I assume it needs the parameter for some reason)

Yes, it's the parameter debug location we're worried about here, as it's a "local value" and code was changed to update location for local values.

[sdmitrouk]

Addressing David's comments.

[sdmitrouk]

Hey Alexey, this patch might be of interest for you with regard to issues you face in code coverage tools and might fix some problems with debug locations there. Please take a look if you can.

[samsonov]

Right. I'm happy with the direction of this patch, and think that removing some of cross-basic-block fallthrough is a positive behavior change. This is orthogonal to the work I plan to do in https://llvm.org/bugs/show_bug.cgi?id=23837, but your change may improve things for end users. I can't comment on the patch implementation, as I know too little of SelectionDAG internals, but please proceed once the reviewers are happy with this change :)

[sdmitrouk]

Ping.

[sdmitrouk]

Ping.

[dblaikie]

I was hoping to punt this to Alexey, but that seems to have failed (or succeeded only partially) & we perhaps need a FastISel person to take a look...

[samsonov]

Yes, I think so... I'm happy with the patch, but would prefer someone with more knowledge of ISel to sign this off.

[sdmitrouk]

Ping.
@mcrosier maybe you could take a look at these changes since you're listed as Fast-ISel code owner?

[sdmitrouk]

Ping.

[sdmitrouk]

Ping.

[sdmitrouk]

Ping.

[dblaikie]

We might need to, a bit more explicitly, rope someone in.

Anyone know who we should talk to about ISel stuff to get their side of the
review on this patch? (Chad, Eric - could you guys point us in any
particular direction/throw someone under the bus?)

[dblaikie]

(switching to the right/new llvm mailing list)

[sdmitrouk]

David, I asked Chad two weeks ago about review or someone who could make a review, that's why he added @ributzka, but if Juergen doesn't have time, getting attention of another person competent in this area would be nice.

[echristo]

I apologize for the delay on this patch, I'm taking a look at it. I think I have some comments so I'm going to take a bit extra time and look at a couple of other things.

Thanks!

-eric

[sdmitrouk]

Ping. Eric, any comments on this patch?

[sdmitrouk]

Ping.

[sdmitrouk]

Ping.

[sdmitrouk]

Ping.

[echristo]

Hi, I apologize for the delay on this.

So, this is a hack on top of a hack on top of an optimization :)

Basically the "right" thing we should do is emit location information on constant loads. However, that was removed a while back IIRC by (or because of) Paul as stepping through code would jump around quite a bit because of the optimization where we only want to load a particular constant once and so we load it at the top of the block with the last location used.

I think the best thing for this would be either to remove the hack where we don't put locations on constant loads (which will lead us back to jumping around in blocks) or we can come up with a better optimization to handle "we actually want the constant load as close to the use as possible without multiple constant loads".

Thoughts?

-eric

[probinson]

that was removed a while back IIRC by (or because of) Paul

"It was that way when I found it."

Loading constants at the top of the (sub-)block, with no attached location, is how things stood when I took my first crack at it. Having the first instruction in a block inherit a source location from the tail of the physically preceding block is obviously not good. Attaching the original source location to the constant load isn't really better, because of the jumping-around thing.

My original patch had problems, which is one reason it didn't go in (or went in and came back out, I don't recall). We've been carrying it locally and most recently Wolfgang Pieb has been tweaking it. I've cc'd him.

I guess my real fundamental question is: Why does FastISel work backwards from the end of the block anyhow? I'm pretty sure we've seen cases where a bunch of constants get loaded up front, then there's so much register pressure that you start seeing spills. Working forward from the beginning, constants would be loaded as they are needed, and can hang around for re-use later in the block without screwing up source location info. I think we'd see less spilling and for sure the source location info would be smoother.

[dblaikie]

I think this is probably a good thing. Let's go for it - it's not too convoluted/going to weigh the codebase down much.

[dblaikie]

(un-accept, didn't mean to override some of the thread context & I missed it while reading back over this - so going back to a "discussion" state)

my basic thinking is: We know some instructions will never have locations on them (synthesized instructions for various reasons, etc) & if those instructions ever end up at the start of a block we'll probably get bad behavior (because they'll be assigned to whatever location is at the end of the block that happens to be laid out prior to this one) so we'll want this backpropagation regardless of any fixes we make to constants.

Yes, putting single-use constants at their use would be nice/good/better (especially for things like asan), maybe even putting multi-use constants at their first use (is that always possible, though? do we ever propagate a constant load from two basic blocks into a common prior block for example?) if possible.

[echristo]

In D9887#327337, @dblaikie wrote:

(un-accept, didn't mean to override some of the thread context & I missed it while reading back over this - so going back to a "discussion" state)

my basic thinking is: We know some instructions will never have locations on them (synthesized instructions for various reasons, etc) & if those instructions ever end up at the start of a block we'll probably get bad behavior (because they'll be assigned to whatever location is at the end of the block that happens to be laid out prior to this one) so we'll want this backpropagation regardless of any fixes we make to constants.

Yes, putting single-use constants at their use would be nice/good/better (especially for things like asan), maybe even putting multi-use constants at their first use (is that always possible, though? do we ever propagate a constant load from two basic blocks into a common prior block for example?) if possible.

This is a pretty compelling argument, another thought is can we just assume line/column 0 on anything that doesn't have a location and actually use that in the output line table? Will gdb/lldb/other debuggers skip over things (this will help in the "what if we have a block with no instructions with locations on it" issue here) or will they do something silly?

[aprantl]

In D9887#327352, @echristo wrote:

This is a pretty compelling argument, another thought is can we just assume line/column 0 on anything that doesn't have a location and actually use that in the output line table? Will gdb/lldb/other debuggers skip over things (this will help in the "what if we have a block with no instructions with locations on it" issue here) or will they do something silly?

I can only speak for LLDB, but LLDB will correctly skip over any line 0 locations.

[probinson]

In D9887#327337, @dblaikie wrote:

(un-accept, didn't mean to override some of the thread context & I missed it while reading back over this - so going back to a "discussion" state)

my basic thinking is: We know some instructions will never have locations on them (synthesized instructions for various reasons, etc) & if those instructions ever end up at the start of a block we'll probably get bad behavior (because they'll be assigned to whatever location is at the end of the block that happens to be laid out prior to this one) so we'll want this backpropagation regardless of any fixes we make to constants.

Yes, putting single-use constants at their use would be nice/good/better (especially for things like asan), maybe even putting multi-use constants at their first use (is that always possible, though? do we ever propagate a constant load from two basic blocks into a common prior block for example?) if possible.

FastISel is never going to hoist anything across basic-block boundaries. It never looks at more than one block at a time. FastISel is used only at -O0; would there ever be a post-ISel pass at -O0 that tried to do that kind of hoisting?

Conceptually, FastISel probably could do enough bookkeeping to be able to push a constant-materialization _down_ to the first use, which might be worth it just to save spills/restores. If the instructions did get pushed down to the first use, they could then be given the same debug loc as the use, which at least can't be any worse than things are now.

That would still potentially leave instructions at the top of the block that deal with phis, though, wouldn't it? which kind of inherently don't have debug locations, so shuffling the local-value instructions around doesn't fully solve the top-of-block problem.

[echristo]

In D9887#327542, @probinson wrote:

In D9887#327337, @dblaikie wrote:

(un-accept, didn't mean to override some of the thread context & I missed it while reading back over this - so going back to a "discussion" state)

my basic thinking is: We know some instructions will never have locations on them (synthesized instructions for various reasons, etc) & if those instructions ever end up at the start of a block we'll probably get bad behavior (because they'll be assigned to whatever location is at the end of the block that happens to be laid out prior to this one) so we'll want this backpropagation regardless of any fixes we make to constants.

Yes, putting single-use constants at their use would be nice/good/better (especially for things like asan), maybe even putting multi-use constants at their first use (is that always possible, though? do we ever propagate a constant load from two basic blocks into a common prior block for example?) if possible.

FastISel is never going to hoist anything across basic-block boundaries. It never looks at more than one block at a time. FastISel is used only at -O0; would there ever be a post-ISel pass at -O0 that tried to do that kind of hoisting?

Not necessarily the case. Imagine a use where isel time is important, but running a couple of optimizations after isn't quite as important.

Conceptually, FastISel probably could do enough bookkeeping to be able to push a constant-materialization _down_ to the first use, which might be worth it just to save spills/restores. If the instructions did get pushed down to the first use, they could then be given the same debug loc as the use, which at least can't be any worse than things are now.

That would still potentially leave instructions at the top of the block that deal with phis, though, wouldn't it? which kind of inherently don't have debug locations, so shuffling the local-value instructions around doesn't fully solve the top-of-block problem.

See the other solution that I mentioned :)

[probinson]

In D9887#327543, @echristo wrote:

See the other solution that I mentioned :)

I did, and I've asked the debugger lead. Hopefully will have an answer tomorrow (he's in England).

Looking at the original example, it sounds like you're suggesting we would produce something like this:

BB#0:
    .loc 1 2 3
    call ...
    <constant load>
    .loc 1 5 6
    ...

BB#1:
    .loc 1 0 0
    <constant load>
    .loc 1 3 4
    ...

Am I understanding this correctly? It sure would be less bookkeeping.

I guess for single-stepping purposes, we want the debugger to just keep going until it found an instruction with a non-zero line number. For interspersed-source-display purposes, the line-zero instruction would want to be associated with .loc 1 3 4 rather than .loc 1 5 6.

[probinson]

In D9887#327552, @probinson wrote:

In D9887#327543, @echristo wrote:

See the other solution that I mentioned :)

I did, and I've asked the debugger lead. Hopefully will have an answer tomorrow (he's in England).

Currently, the SCE debugger ignores line-0 records, but we could retain them and arrange not to stop on those instructions.

[aprantl]

Eric, can you find out whether gdb can deal with line 0 entries?

[friss]

In D9887#327352, @echristo wrote:

In D9887#327337, @dblaikie wrote:

(un-accept, didn't mean to override some of the thread context & I missed it while reading back over this - so going back to a "discussion" state)

my basic thinking is: We know some instructions will never have locations on them (synthesized instructions for various reasons, etc) & if those instructions ever end up at the start of a block we'll probably get bad behavior (because they'll be assigned to whatever location is at the end of the block that happens to be laid out prior to this one) so we'll want this backpropagation regardless of any fixes we make to constants.

Yes, putting single-use constants at their use would be nice/good/better (especially for things like asan), maybe even putting multi-use constants at their first use (is that always possible, though? do we ever propagate a constant load from two basic blocks into a common prior block for example?) if possible.

Note that I played with this a while ago and it's not trivial to get right. The biggest issue is that the generation of a local constant might trigger the generation of other constants that it depends on. So you have to do book keeping not at the instruction level, but by groups. I stopped working on it because I thought the added complexity (and I suppose runtime cost) didn't fit into FastISel.

This is a pretty compelling argument, another thought is can we just assume line/column 0 on anything that doesn't have a location and actually use that in the output line table? Will gdb/lldb/other debuggers skip over things (this will help in the "what if we have a block with no instructions with locations on it" issue here) or will they do something silly?

While I really like the simplicity of that (if debuggers can cope), it means that the line table will have 0 entries at the beginning of most (I'm guessing the 'most' part here) basic blocks, which would make them much bigger (and thus slower to write out). If my fears are unfounded, then I think this 0 idea is by far the best compromise!

[probinson]

In D9887#328125, @friss wrote:

While I really like the simplicity of that (if debuggers can cope), it means that the line table will have 0 entries at the beginning of most (I'm guessing the 'most' part here) basic blocks, which would make them much bigger (and thus slower to write out). If my fears are unfounded, then I think this 0 idea is by far the best compromise!

If we say that we just have to set the line number, and not the file and column numbers, I think "much bigger" is not real. Setting line number to 0 typically would require a DW_LNS_advance_line which is 1 byte plus the SLEB128-encoded offset, i.e. the negative of the current line number. (We'll assume that we don't need to reset the current file or column.) Then it would take another one to put the line number back. That would generally be 4 or 6 bytes per basic-block-that-had-these-instructions, for source files up to ~8K lines.

Emitting column numbers probably costs about as much, if not more (generally 2 bytes each time the column number changes), with less clear benefit. Generating some actual data would be nice, of course, but I'm not inclined to worry about it.

[friss]

I implemented the line 0 idea in http://reviews.llvm.org/D16569

include/llvm/CodeGen/FastISel.h

void setLastLocalValue(MachineInstr *I) {
     EmitStartPt = I;
     LastLocalValue = I;
   }
 
   /// \brief Set the current block to which generated machine instructions will
   /// be appended, and clear the local CSE map.
   void startNewBlock();
 
+  /// \brief Performs post-processing of complete basic block.
+  void finishBasicBlock();
+
   /// \brief Return current debug location information.
   DebugLoc getCurDebugLoc() const { return DbgLoc; }
 
   /// \brief Do "fast" instruction selection for function arguments and append
   /// the machine instructions to the current block. Returns true when
   /// successful.
   bool lowerArguments();
 
private:
 
   /// \brief Add a stackmap or patchpoint intrinsic call's live variable
   /// operands to a stackmap or patchpoint machine instruction.
   bool addStackMapLiveVars(SmallVectorImpl<MachineOperand> &Ops,
                            const CallInst *CI, unsigned StartIdx);
   bool lowerCallOperands(const CallInst *CI, unsigned ArgIdx, unsigned NumArgs,
                          const Value *Callee, bool ForceRetVoidTy,
                          CallLoweringInfo &CLI);
+
+  /// \brief Copies first non-empty debug location from list of instructions as
+  /// starting location for current block.
+  /// \param BlockFinished Whether whole block was processed at this point.
+  void fixupLocalValueLocations(bool BlockFinished);
 };
 
 } // end namespace llvm
 
 #endif

lib/CodeGen/SelectionDAG/FastISel.cpp

void FastISel::startNewBlock() {
   // contains labels or copies, use the last instruction as the last local
   // value.
   EmitStartPt = nullptr;
   if (!FuncInfo.MBB->empty())
     EmitStartPt = &FuncInfo.MBB->back();
   LastLocalValue = EmitStartPt;
 }
 
+void FastISel::finishBasicBlock() {
+  fixupLocalValueLocations(true);
+}
+
+void FastISel::fixupLocalValueLocations(bool BlockFinished) {
+  bool IsEntryBlock =
+      (FuncInfo.MBB == FuncInfo.MBBMap[&FuncInfo.Fn->getEntryBlock()]);
+
+  // If this is the wrap-up stage of block processing, and any local-value
+  // instructions are _not_ at the very beginning of the block, then we should
+  // _not_ update their debug info.
+  //
+  // Skip entry basic block to do not move "prologue_end" location above stack
+  // adjustment.
+  if (BlockFinished && (EmitStartPt || IsEntryBlock))
+    return;
+
+  // Nothing to do if we didn't emit any local values.
+  if (LocalValueMap.empty())
+    return;
+
+  // Find first local value.
+  MachineBasicBlock::iterator FirstLocalValue;
+  if (EmitStartPt) {
+    FirstLocalValue = EmitStartPt;
+    ++FirstLocalValue;
+  } else {
+    FirstLocalValue = FuncInfo.MBB->getFirstNonPHI();
+  }
+
+  // Find first instruction with non-null debug location.
+  auto InstWithLoc = std::find_if(FuncInfo.InsertPt, FuncInfo.MBB->end(),
+                                  std::mem_fn(&MachineInstr::getDebugLoc));
+  if (InstWithLoc != FuncInfo.MBB->end())
+    FirstLocalValue->setDebugLoc(InstWithLoc->getDebugLoc());
+}
+
 bool FastISel::lowerArguments() {
   if (!FuncInfo.CanLowerReturn)
     // Fallback to SDISel argument lowering code to deal with sret pointer
     // parameter.
     return false;
 
   if (!fastLowerArguments())
     return false;
 
   // Enter arguments into ValueMap for uses in non-entry BBs.
   for (Function::const_arg_iterator I = FuncInfo.Fn->arg_begin(),
                                     E = FuncInfo.Fn->arg_end();
        I != E; ++I) {
     DenseMap<const Value *, unsigned>::iterator VI = LocalValueMap.find(I);
     assert(VI != LocalValueMap.end() && "Missed an argument?");
     FuncInfo.ValueMap[I] = VI->second;
   }
   return true;
 }
 
 void FastISel::flushLocalValueMap() {
+  fixupLocalValueLocations(false);
   LocalValueMap.clear();
   LastLocalValue = EmitStartPt;
   recomputeInsertPt();
   SavedInsertPt = FuncInfo.InsertPt;
 }
 
 bool FastISel::hasTrivialKill(const Value *V) {
   // Don't consider constants or arguments to have trivial kills.

lib/CodeGen/SelectionDAG/SelectionDAGISel.cpp

if (Begin != BI) {
       // Run SelectionDAG instruction selection on the remainder of the block
       // not handled by FastISel. If FastISel is not run, this is the entire
       // block.
       bool HadTailCall;
       SelectBasicBlock(Begin, BI, HadTailCall);
     }
 
     FinishBasicBlock();
+    if (FastIS)
+      FastIS->finishBasicBlock();
     FuncInfo->PHINodesToUpdate.clear();
   }
 
   delete FastIS;
   SDB->clearDanglingDebugInfo();
   SDB->SPDescriptor.resetPerFunctionState();
 }
 

test/DebugInfo/ARM/single-constant-use-preserves-dbgloc.ll

 ; RUN: llc -filetype=asm -asm-verbose=0 < %s | FileCheck %s
+; RUN: llc -fast-isel -filetype=asm -asm-verbose=0 < %s | FileCheck %s
 
 ; int main()
 ; {
 ;     int x = 0;
 ;     if (x > 0)
 ;         return x;
 ;     x = -1; // <== this line should have correct debug location
 ;     return -1;

test/DebugInfo/X86/dbg-line-fast-isel.ll

+; RUN: llc -disable-fp-elim -O0 %s -o - | FileCheck %s
+
+target datalayout = "e-m:e-i64:64-f80:128-n8:16:32:64-S128"
+target triple = "x86_64-unknown-linux-gnu"
+
+; xx // return value generates non-empty prologue for
+; xx // isel_line_test_prologue_dbginfo
+; 01 void callme(int);
+; 02
+; 03 int isel_line_test_subblocks(int arg)
+; 04 {
+; 05   if (arg > 5000)
+; xx     // "200" should have correct location
+; 06     callme(200);
+; xx   // getting here from either of predecessors should yield correct debug
+; xx   // location for 300, so location should be inside this block
+; 07   callme(300);
+; xx   // location for "0" constant after the call in the middle of a block
+; xx   // should be correct
+; 08   return 0;
+; 09 }
+; 10
+; 11 void isel_line_test_prologue_dbginfo()
+; 12 {
+; 13   callme(400);
+; 14 }
+
+; Function Attrs: nounwind uwtable
+define i32 @isel_line_test_subblocks(i32 %arg) {
+; The start of each non-entry block (or sub-block) should get a .loc directive.
+; CHECK:       isel_line_test_subblocks:
+; CHECK:       # BB#1:
+; CHECK-NEXT:  .loc 1 6 5
+; CHECK:       LBB0_2:
+; CHECK-NEXT:  .loc 1 7 3
+; CHECK:       callq callme
+; CHECK-NEXT:  .loc 1 8 3
+
+entry:
+  %arg.addr = alloca i32, align 4
+  store i32 %arg, i32* %arg.addr, align 4
+  call void @llvm.dbg.declare(metadata i32* %arg.addr, metadata !14, metadata !15), !dbg !16
+  %0 = load i32, i32* %arg.addr, align 4, !dbg !17
+  %cmp = icmp sgt i32 %0, 5000, !dbg !19
+  br i1 %cmp, label %if.then, label %if.end, !dbg !20
+
+if.then:                                          ; preds = %entry
+  call void @callme(i32 200), !dbg !21
+  br label %if.end, !dbg !21
+
+if.end:                                           ; preds = %if.then, %entry
+  call void @callme(i32 300), !dbg !22
+  ret i32 0, !dbg !23
+}
+
+; Function Attrs: nounwind readnone
+declare void @llvm.dbg.declare(metadata, metadata, metadata)
+
+declare void @callme(i32)
+
+; Function Attrs: nounwind uwtable
+define void @isel_line_test_prologue_dbginfo() {
+; The stack adjustment should be part of the prologue.
+; CHECK: isel_line_test_prologue_dbginfo:
+; CHECK: movq %rsp, %rbp
+; CHECK: .loc 1 13 3 prologue_end
+
+entry:
+  call void @callme(i32 400), !dbg !24
+  ret void, !dbg !25
+}
+
+!llvm.dbg.cu = !{!0}
+!llvm.module.flags = !{!11, !12}
+
+!0 = !DICompileUnit(language: DW_LANG_C99, file: !1, isOptimized: false, runtimeVersion: 0, emissionKind: 1, enums: !2, retainedTypes: !2, subprograms: !3, globals: !2, imports: !2)
+!1 = !DIFile(filename: "fast-isel.c", directory: "")
+!2 = !{}
+!3 = !{!4, !8}
+!4 = !DISubprogram(name: "isel_line_test_subblocks", scope: !1, file: !1, line: 3, type: !5, isLocal: false, isDefinition: true, scopeLine: 4, flags: DIFlagPrototyped, isOptimized: false, function: i32 (i32)* @isel_line_test_subblocks, variables: !2)
+!5 = !DISubroutineType(types: !6)
+!6 = !{!7, !7}
+!7 = !DIBasicType(name: "int", size: 32, align: 32, encoding: DW_ATE_signed)
+!8 = !DISubprogram(name: "isel_line_test_prologue_dbginfo", scope: !1, file: !1, line: 11, type: !9, isLocal: false, isDefinition: true, scopeLine: 12, isOptimized: false, function: void ()* @isel_line_test_prologue_dbginfo, variables: !2)
+!9 = !DISubroutineType(types: !10)
+!10 = !{null}
+!11 = !{i32 2, !"Dwarf Version", i32 4}
+!12 = !{i32 2, !"Debug Info Version", i32 3}
+!14 = !DILocalVariable(tag: DW_TAG_arg_variable, name: "arg", arg: 1, scope: !4, file: !1, line: 3, type: !7)
+!15 = !DIExpression()
+!16 = !DILocation(line: 3, column: 34, scope: !4)
+!17 = !DILocation(line: 5, column: 7, scope: !18)
+!18 = distinct !DILexicalBlock(scope: !4, file: !1, line: 5, column: 7)
+!19 = !DILocation(line: 5, column: 11, scope: !18)
+!20 = !DILocation(line: 5, column: 7, scope: !4)
+!21 = !DILocation(line: 6, column: 5, scope: !18)
+!22 = !DILocation(line: 7, column: 3, scope: !4)
+!23 = !DILocation(line: 8, column: 3, scope: !4)
+!24 = !DILocation(line: 13, column: 3, scope: !8)
+!25 = !DILocation(line: 14, column: 1, scope: !8)