[DebugInfo] Limit the size of DIExpressions that we will salvage up to

[StephenTozer]

Summary

Fixes: https://bugs.llvm.org/show_bug.cgi?id=51841

This patch places an arbitrary limit on the size of DIExpressions that we will produce via salvaging, for performance reasons. This helps to fix a performance issue observed in the bug above, in which debug values would be salvaged hundreds of times, producing expressions with over 1000 elements and causing the compiler to hang. Limiting the size of debug values that we will produce to 128 largely fixes this issue.

It should be noted that this is not the only issue related to the bug above; InstCombine is also quadratically growing the number of debug intrinsics with each block it moves through, resulting in the number of intrinsics growing from 4561 to 70710 despite the fact that not a single one of the new intrinsics adds useful debug info. There are potential fixes for this, but I believe the problem of unlimited salvaging will still be an issue even if we smarten up InstCombine, as we can still legitimately salvage thousands of intrinsics thousands of times each before we determine that the resulting intrinsics provide no useful info. As such, I think this patch is probably a necessity that we can aim to reduce our dependence on with further changes.

[spatel]

Thanks for working on this! I don't know anything about debug info/salvaging implementation, so I can't review the patch, but I hope someone else will have a look.

Could this reduce compile time in this config:
https://llvm-compile-time-tracker.com/?config=NewPM-ReleaseLTO-g&stat=instructions ?

If so, it would be good to know that number before committing - maybe tune the MaxExpressionSize setting for most benefit based on those benchmarks.

[dblaikie]

(would need test coverage - which might help answer my main question: What sort of large expressions are observed in practice? Could they be simplified, rather than dropped? (I think it's probably still right/good to have a limit, but if hitting the limit is often reflective of some suboptimal representational choice in how the dwarf expression is formed, that could be optimized down to something more compact - that's something to be aware of/keep an eye on probably))

[StephenTozer]

In D110332#3018654, @dblaikie wrote:

(would need test coverage - which might help answer my main question: What sort of large expressions are observed in practice? Could they be simplified, rather than dropped? (I think it's probably still right/good to have a limit, but if hitting the limit is often reflective of some suboptimal representational choice in how the dwarf expression is formed, that could be optimized down to something more compact - that's something to be aware of/keep an eye on probably))

In the bug above, the limit is hit due to this loop:

for (*f = 4; *f <= 33; *f += 1)
  for (b = -27; b <= 48; b++) {
    int16_t g;
    int32_t *i = e;
    (c -= 10) % (g = c ^= i != 0);
    a &= b;
  }

This loop is ultimately unrolled and optimized into a chain of ~4000 add and xor instructions, for which every xor has an associated debug value:

%sub.29.5 = add nsw i32 %xor.29.4, -10, !dbg !51
%xor.29.5 = xor i32 %sub.29.5, 1, !dbg !52
call void @llvm.dbg.value(metadata i32 %xor.29.5, metadata !31, metadata !DIExpression(DW_OP_LLVM_convert, 32, DW_ATE_unsigned, DW_OP_LLVM_convert, 16, DW_ATE_unsigned, DW_OP_stack_value)), !dbg !50
%sub.29.6 = add nsw i32 %xor.29.5, -10, !dbg !51
%xor.29.6 = xor i32 %sub.29.6, 1, !dbg !52
call void @llvm.dbg.value(metadata i32 %xor.29.6, metadata !31, metadata !DIExpression(DW_OP_LLVM_convert, 32, DW_ATE_unsigned, DW_OP_LLVM_convert, 16, DW_ATE_unsigned, DW_OP_stack_value)), !dbg !5
etc...

InstCombine shuffles these instructions around, and due to the way that we handle lost debug values this results in us trying to salvage back down this chain of instructions. This is what we would actually want to do in a lot of real cases, it just happens that in this case there is a prohibitive number of instructions we would have to salvage through in order to recover the debug value. I would definitely be in favour of implementing const-folding in expressions as a means of preventing us from hitting the limit, but it doesn't seem possible in this case.

For what it's worth , in this specific case the salvaged dbg.values are also useless since they form into a huge consecutive block with no instructions in-between - but 1) I think the IR could be modified such that this wasn't the case for at least some of the intrinsics, and 2) without making a much larger change to InstCombine, I don't think we can know that the intrinsics will be useless before we've finished the salvaging.

[dblaikie]

In D110332#3018752, @StephenTozer wrote:

In D110332#3018654, @dblaikie wrote:

(would need test coverage - which might help answer my main question: What sort of large expressions are observed in practice? Could they be simplified, rather than dropped? (I think it's probably still right/good to have a limit, but if hitting the limit is often reflective of some suboptimal representational choice in how the dwarf expression is formed, that could be optimized down to something more compact - that's something to be aware of/keep an eye on probably))

In the bug above, the limit is hit due to this loop:

for (*f = 4; *f <= 33; *f += 1)
  for (b = -27; b <= 48; b++) {
    int16_t g;
    int32_t *i = e;
    (c -= 10) % (g = c ^= i != 0);
    a &= b;
  }

This loop is ultimately unrolled and optimized into a chain of ~4000 add and xor instructions, for which every xor has an associated debug value:

%sub.29.5 = add nsw i32 %xor.29.4, -10, !dbg !51
%xor.29.5 = xor i32 %sub.29.5, 1, !dbg !52
call void @llvm.dbg.value(metadata i32 %xor.29.5, metadata !31, metadata !DIExpression(DW_OP_LLVM_convert, 32, DW_ATE_unsigned, DW_OP_LLVM_convert, 16, DW_ATE_unsigned, DW_OP_stack_value)), !dbg !50
%sub.29.6 = add nsw i32 %xor.29.5, -10, !dbg !51
%xor.29.6 = xor i32 %sub.29.6, 1, !dbg !52
call void @llvm.dbg.value(metadata i32 %xor.29.6, metadata !31, metadata !DIExpression(DW_OP_LLVM_convert, 32, DW_ATE_unsigned, DW_OP_LLVM_convert, 16, DW_ATE_unsigned, DW_OP_stack_value)), !dbg !5
etc...

InstCombine shuffles these instructions around, and due to the way that we handle lost debug values this results in us trying to salvage back down this chain of instructions. This is what we would actually want to do in a lot of real cases, it just happens that in this case there is a prohibitive number of instructions we would have to salvage through in order to recover the debug value. I would definitely be in favour of implementing const-folding in expressions as a means of preventing us from hitting the limit, but it doesn't seem possible in this case.

For what it's worth , in this specific case the salvaged dbg.values are also useless since they form into a huge consecutive block with no instructions in-between - but 1) I think the IR could be modified such that this wasn't the case for at least some of the intrinsics, and 2) without making a much larger change to InstCombine, I don't think we can know that the intrinsics will be useless before we've finished the salvaging.

Fair enough - thanks for bearing with me!

[StephenTozer]

Added test.

[jmorse]

LGTM, with naming suggestion inline

llvm/lib/Transforms/Utils/Local.cpp

3–1

IMO, "Valid" is the wrong term to use here as it suggests a correctness problem. Could I suggest "IsDesirableSalvageExpr"?

[StephenTozer]

In D110332#3018090, @spatel wrote:

Thanks for working on this! I don't know anything about debug info/salvaging implementation, so I can't review the patch, but I hope someone else will have a look.

Could this reduce compile time in this config:
https://llvm-compile-time-tracker.com/?config=NewPM-ReleaseLTO-g&stat=instructions ?

If so, it would be good to know that number before committing - maybe tune the MaxExpressionSize setting for most benefit based on those benchmarks.

I've tested a few different versions on the compile time tracker, but I'm afraid I can't see any measurable difference - probably because most programs will never hit this limit to begin with, so it makes little difference performance-wise where we draw the line. With respect to the reported broken file, the most significant performance impact of lengthening the allowed expressions is increasing the size of the intermediate file (so memory usage, and disk space if the intermediate file is saved). In terms of performance, there doesn't seem to be a huge difference, but 128 seems a good medium to draw it at. We could go down to 64, since most programs will never hit that with a legitimate expression anyway, but 128 is already low enough to make the pathological cases manageable, so we have enough leeway to support potentially very large expressions.

[spatel]

In D110332#3066881, @StephenTozer wrote:

In D110332#3018090, @spatel wrote:

Thanks for working on this! I don't know anything about debug info/salvaging implementation, so I can't review the patch, but I hope someone else will have a look.

Could this reduce compile time in this config:
https://llvm-compile-time-tracker.com/?config=NewPM-ReleaseLTO-g&stat=instructions ?

If so, it would be good to know that number before committing - maybe tune the MaxExpressionSize setting for most benefit based on those benchmarks.

I've tested a few different versions on the compile time tracker, but I'm afraid I can't see any measurable difference - probably because most programs will never hit this limit to begin with, so it makes little difference performance-wise where we draw the line. With respect to the reported broken file, the most significant performance impact of lengthening the allowed expressions is increasing the size of the intermediate file (so memory usage, and disk space if the intermediate file is saved). In terms of performance, there doesn't seem to be a huge difference, but 128 seems a good medium to draw it at. We could go down to 64, since most programs will never hit that with a legitimate expression anyway, but 128 is already low enough to make the pathological cases manageable, so we have enough leeway to support potentially very large expressions.

Sounds good. Thanks for checking.

llvm/lib/Transforms/Utils/Local.cpp

 //===- Local.cpp - Functions to perform local transformations -------------===//
 //
 // Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions.
 // See https://llvm.org/LICENSE.txt for license information.
 // SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
 //
 //===----------------------------------------------------------------------===//
 //
 // This family of functions perform various local transformations to the

 void llvm::salvageDebugInfo(Instruction &I) {
   SmallVector<DbgVariableIntrinsic *, 1> DbgUsers;
   findDbgUsers(DbgUsers, &I);
   salvageDebugInfoForDbgValues(I, DbgUsers);
 }
 
 void llvm::salvageDebugInfoForDbgValues(
     Instruction &I, ArrayRef<DbgVariableIntrinsic *> DbgUsers) {
-  // This is an arbitrary chosen limit on the maximum number of values we can
-  // salvage up to in a DIArgList, used for performance reasons.
+  // These are arbitrary chosen limits on the maximum number of values and the
+  // maximum size of a debug expression we can salvage up to, used for
+  // performance reasons.
   const unsigned MaxDebugArgs = 16;
+  const unsigned MaxExpressionSize = 128;
   bool Salvaged = false;
 
   for (auto *DII : DbgUsers) {
     // Do not add DW_OP_stack_value for DbgDeclare and DbgAddr, because they
     // are implicitly pointing out the value as a DWARF memory location
     // description.
     bool StackValue = isa<DbgValueInst>(DII);
     auto DIILocation = DII->location_ops();
while (SalvagedExpr && LocItr != DIILocation.end()) {
       LocItr = std::find(++LocItr, DIILocation.end(), &I);
     }
     // salvageDebugInfoImpl should fail on examining the first element of
     // DbgUsers, or none of them.
     if (!Op0)
       break;
 
     DII->replaceVariableLocationOp(&I, Op0);
-    if (AdditionalValues.empty()) {
+    bool IsValidSalvageExpr = SalvagedExpr->getNumElements() <= MaxExpressionSize;
+    if (AdditionalValues.empty() && IsValidSalvageExpr) {
       DII->setExpression(SalvagedExpr);
-    } else if (isa<DbgValueInst>(DII) &&
+    } else if (isa<DbgValueInst>(DII) && IsValidSalvageExpr &&
                DII->getNumVariableLocationOps() + AdditionalValues.size() <=
                    MaxDebugArgs) {
       DII->addVariableLocationOps(AdditionalValues, SalvagedExpr);
     } else {
       // Do not salvage using DIArgList for dbg.addr/dbg.declare, as it is
       // currently only valid for stack value expressions.
       // Also do not salvage if the resulting DIArgList would contain an
       // unreasonably large number of values.

llvm/test/DebugInfo/salvage-limit-expr-size.ll

+; RUN: opt %s -dce -S | FileCheck %s
+
+;; Tests that a DIExpression will only be salvaged up to a certain length, and
+;; will produce an undef value if an expression would need to exceed that length.
+
+define i32 @"?multiply@@YAHHH@Z"(i32 %a, i32 %b) !dbg !8 {
+entry:
+  %add.1 = add nsw i32 %a, 5, !dbg !14
+  %add.2 = add nsw i32 %a, %b, !dbg !14
+  ;; These expressions should salvage successfully, up to exactly 128 elements.
+  ; CHECK: call void @llvm.dbg.value(metadata i32 %a, metadata ![[VAR_C:[0-9]+]]
+  ; CHECK-NEXT: call void @llvm.dbg.value(metadata !DIArgList(i32 %a, i32 %b), metadata ![[VAR_C]]
+  call void @llvm.dbg.value(metadata i32 %add.1, metadata !12, metadata !DIExpression(DW_OP_constu, 1, DW_OP_plus, DW_OP_plus_uconst, 1, DW_OP_plus_uconst, 1, DW_OP_plus_uconst, 1, DW_OP_plus_uconst, 1, DW_OP_plus_uconst, 1, DW_OP_plus_uconst, 1, DW_OP_plus_uconst, 1, DW_OP_plus_uconst, 1, DW_OP_plus_uconst, 1, DW_OP_plus_uconst, 1, DW_OP_plus_uconst, 1, DW_OP_plus_uconst, 1, DW_OP_plus_uconst, 1, DW_OP_plus_uconst, 1, DW_OP_plus_uconst, 1, DW_OP_plus_uconst, 1, DW_OP_plus_uconst, 1, DW_OP_plus_uconst, 1, DW_OP_plus_uconst, 1, DW_OP_plus_uconst, 1, DW_OP_plus_uconst, 1, DW_OP_plus_uconst, 1, DW_OP_plus_uconst, 1, DW_OP_plus_uconst, 1, DW_OP_plus_uconst, 1, DW_OP_plus_uconst, 1, DW_OP_plus_uconst, 1, DW_OP_plus_uconst, 1, DW_OP_plus_uconst, 1, DW_OP_plus_uconst, 1, DW_OP_plus_uconst, 1, DW_OP_plus_uconst, 1, DW_OP_plus_uconst, 1, DW_OP_plus_uconst, 1, DW_OP_plus_uconst, 1, DW_OP_plus_uconst, 1, DW_OP_plus_uconst, 1, DW_OP_plus_uconst, 1, DW_OP_plus_uconst, 1, DW_OP_plus_uconst, 1, DW_OP_plus_uconst, 1, DW_OP_plus_uconst, 1, DW_OP_plus_uconst, 1, DW_OP_plus_uconst, 1, DW_OP_plus_uconst, 1, DW_OP_plus_uconst, 1, DW_OP_plus_uconst, 1, DW_OP_plus_uconst, 1, DW_OP_plus_uconst, 1, DW_OP_plus_uconst, 1, DW_OP_plus_uconst, 1, DW_OP_plus_uconst, 1, DW_OP_plus_uconst, 1, DW_OP_plus_uconst, 1, DW_OP_plus_uconst, 1, DW_OP_plus_uconst, 1, DW_OP_plus_uconst, 1, DW_OP_plus_uconst, 1, DW_OP_plus_uconst, 1, DW_OP_plus_uconst, 1, DW_OP_plus_uconst, 1, DW_OP_stack_value)), !dbg !13
+  call void @llvm.dbg.value(metadata i32 %add.2, metadata !12, metadata !DIExpression(DW_OP_plus_uconst, 1, DW_OP_plus_uconst, 1, DW_OP_plus_uconst, 1, DW_OP_plus_uconst, 1, DW_OP_plus_uconst, 1, DW_OP_plus_uconst, 1, DW_OP_plus_uconst, 1, DW_OP_plus_uconst, 1, DW_OP_plus_uconst, 1, DW_OP_plus_uconst, 1, DW_OP_plus_uconst, 1, DW_OP_plus_uconst, 1, DW_OP_plus_uconst, 1, DW_OP_plus_uconst, 1, DW_OP_plus_uconst, 1, DW_OP_plus_uconst, 1, DW_OP_plus_uconst, 1, DW_OP_plus_uconst, 1, DW_OP_plus_uconst, 1, DW_OP_plus_uconst, 1, DW_OP_plus_uconst, 1, DW_OP_plus_uconst, 1, DW_OP_plus_uconst, 1, DW_OP_plus_uconst, 1, DW_OP_plus_uconst, 1, DW_OP_plus_uconst, 1, DW_OP_plus_uconst, 1, DW_OP_plus_uconst, 1, DW_OP_plus_uconst, 1, DW_OP_plus_uconst, 1, DW_OP_plus_uconst, 1, DW_OP_plus_uconst, 1, DW_OP_plus_uconst, 1, DW_OP_plus_uconst, 1, DW_OP_plus_uconst, 1, DW_OP_plus_uconst, 1, DW_OP_plus_uconst, 1, DW_OP_plus_uconst, 1, DW_OP_plus_uconst, 1, DW_OP_plus_uconst, 1, DW_OP_plus_uconst, 1, DW_OP_plus_uconst, 1, DW_OP_plus_uconst, 1, DW_OP_plus_uconst, 1, DW_OP_plus_uconst, 1, DW_OP_plus_uconst, 1, DW_OP_plus_uconst, 1, DW_OP_plus_uconst, 1, DW_OP_plus_uconst, 1, DW_OP_plus_uconst, 1, DW_OP_plus_uconst, 1, DW_OP_plus_uconst, 1, DW_OP_plus_uconst, 1, DW_OP_plus_uconst, 1, DW_OP_plus_uconst, 1, DW_OP_plus_uconst, 1, DW_OP_plus_uconst, 1, DW_OP_plus_uconst, 1, DW_OP_plus_uconst, 1, DW_OP_plus_uconst, 1, DW_OP_plus_uconst, 1, DW_OP_stack_value)), !dbg !13
+  ;; These expressions should be set undef, as they would salvage up to exactly 129 elements.
+  ; CHECK-NEXT: call void @llvm.dbg.value(metadata i32 undef, metadata ![[VAR_C]]
+  ; CHECK-NEXT: call void @llvm.dbg.value(metadata i32 undef, metadata ![[VAR_C]]
+  call void @llvm.dbg.value(metadata i32 %add.1, metadata !12, metadata !DIExpression(DW_OP_plus_uconst, 1, DW_OP_plus_uconst, 1, DW_OP_plus_uconst, 1, DW_OP_plus_uconst, 1, DW_OP_plus_uconst, 1, DW_OP_plus_uconst, 1, DW_OP_plus_uconst, 1, DW_OP_plus_uconst, 1, DW_OP_plus_uconst, 1, DW_OP_plus_uconst, 1, DW_OP_plus_uconst, 1, DW_OP_plus_uconst, 1, DW_OP_plus_uconst, 1, DW_OP_plus_uconst, 1, DW_OP_plus_uconst, 1, DW_OP_plus_uconst, 1, DW_OP_plus_uconst, 1, DW_OP_plus_uconst, 1, DW_OP_plus_uconst, 1, DW_OP_plus_uconst, 1, DW_OP_plus_uconst, 1, DW_OP_plus_uconst, 1, DW_OP_plus_uconst, 1, DW_OP_plus_uconst, 1, DW_OP_plus_uconst, 1, DW_OP_plus_uconst, 1, DW_OP_plus_uconst, 1, DW_OP_plus_uconst, 1, DW_OP_plus_uconst, 1, DW_OP_plus_uconst, 1, DW_OP_plus_uconst, 1, DW_OP_plus_uconst, 1, DW_OP_plus_uconst, 1, DW_OP_plus_uconst, 1, DW_OP_plus_uconst, 1, DW_OP_plus_uconst, 1, DW_OP_plus_uconst, 1, DW_OP_plus_uconst, 1, DW_OP_plus_uconst, 1, DW_OP_plus_uconst, 1, DW_OP_plus_uconst, 1, DW_OP_plus_uconst, 1, DW_OP_plus_uconst, 1, DW_OP_plus_uconst, 1, DW_OP_plus_uconst, 1, DW_OP_plus_uconst, 1, DW_OP_plus_uconst, 1, DW_OP_plus_uconst, 1, DW_OP_plus_uconst, 1, DW_OP_plus_uconst, 1, DW_OP_plus_uconst, 1, DW_OP_plus_uconst, 1, DW_OP_plus_uconst, 1, DW_OP_plus_uconst, 1, DW_OP_plus_uconst, 1, DW_OP_plus_uconst, 1, DW_OP_plus_uconst, 1, DW_OP_plus_uconst, 1, DW_OP_plus_uconst, 1, DW_OP_plus_uconst, 1, DW_OP_plus_uconst, 1, DW_OP_plus_uconst, 1, DW_OP_plus_uconst, 1, DW_OP_stack_value)), !dbg !13
+  call void @llvm.dbg.value(metadata i32 %add.2, metadata !12, metadata !DIExpression(DW_OP_constu, 1, DW_OP_plus, DW_OP_plus_uconst, 1, DW_OP_plus_uconst, 1, DW_OP_plus_uconst, 1, DW_OP_plus_uconst, 1, DW_OP_plus_uconst, 1, DW_OP_plus_uconst, 1, DW_OP_plus_uconst, 1, DW_OP_plus_uconst, 1, DW_OP_plus_uconst, 1, DW_OP_plus_uconst, 1, DW_OP_plus_uconst, 1, DW_OP_plus_uconst, 1, DW_OP_plus_uconst, 1, DW_OP_plus_uconst, 1, DW_OP_plus_uconst, 1, DW_OP_plus_uconst, 1, DW_OP_plus_uconst, 1, DW_OP_plus_uconst, 1, DW_OP_plus_uconst, 1, DW_OP_plus_uconst, 1, DW_OP_plus_uconst, 1, DW_OP_plus_uconst, 1, DW_OP_plus_uconst, 1, DW_OP_plus_uconst, 1, DW_OP_plus_uconst, 1, DW_OP_plus_uconst, 1, DW_OP_plus_uconst, 1, DW_OP_plus_uconst, 1, DW_OP_plus_uconst, 1, DW_OP_plus_uconst, 1, DW_OP_plus_uconst, 1, DW_OP_plus_uconst, 1, DW_OP_plus_uconst, 1, DW_OP_plus_uconst, 1, DW_OP_plus_uconst, 1, DW_OP_plus_uconst, 1, DW_OP_plus_uconst, 1, DW_OP_plus_uconst, 1, DW_OP_plus_uconst, 1, DW_OP_plus_uconst, 1, DW_OP_plus_uconst, 1, DW_OP_plus_uconst, 1, DW_OP_plus_uconst, 1, DW_OP_plus_uconst, 1, DW_OP_plus_uconst, 1, DW_OP_plus_uconst, 1, DW_OP_plus_uconst, 1, DW_OP_plus_uconst, 1, DW_OP_plus_uconst, 1, DW_OP_plus_uconst, 1, DW_OP_plus_uconst, 1, DW_OP_plus_uconst, 1, DW_OP_plus_uconst, 1, DW_OP_plus_uconst, 1, DW_OP_plus_uconst, 1, DW_OP_plus_uconst, 1, DW_OP_plus_uconst, 1, DW_OP_plus_uconst, 1, DW_OP_plus_uconst, 1, DW_OP_plus_uconst, 1, DW_OP_stack_value)), !dbg !13
+  %mul = mul nsw i32 %a, %b, !dbg !15
+  ret i32 %mul, !dbg !15
+}
+
+; CHECK: ![[VAR_C]] = !DILocalVariable(name: "c"
+
+declare void @llvm.dbg.value(metadata, metadata, metadata)
+
+!llvm.dbg.cu = !{!0}
+!llvm.module.flags = !{!3, !4, !5, !6}
+!llvm.ident = !{!7}
+
+!0 = distinct !DICompileUnit(language: DW_LANG_C_plus_plus_14, file: !1, producer: "clang version 11.0.0", isOptimized: false, runtimeVersion: 0, emissionKind: FullDebug, enums: !2, nameTableKind: None)
+!1 = !DIFile(filename: "test.cpp", directory: "/")
+!2 = !{}
+!3 = !{i32 2, !"CodeView", i32 1}
+!4 = !{i32 2, !"Debug Info Version", i32 3}
+!5 = !{i32 1, !"wchar_size", i32 2}
+!6 = !{i32 7, !"PIC Level", i32 2}
+!7 = !{!"clang version 11.0.0"}
+!8 = distinct !DISubprogram(name: "multiply", linkageName: "?multiply@@YAHHH@Z", scope: !1, file: !1, line: 1, type: !9, scopeLine: 1, flags: DIFlagPrototyped, spFlags: DISPFlagDefinition, unit: !0, retainedNodes: !2)
+!9 = !DISubroutineType(types: !10)
+!10 = !{!11, !11, !11}
+!11 = !DIBasicType(name: "int", size: 32, encoding: DW_ATE_signed)
+!12 = !DILocalVariable(name: "c", scope: !8, file: !1, line: 2, type: !11)
+!13 = !DILocation(line: 0, scope: !8)
+!14 = !DILocation(line: 2, scope: !8)
+!15 = !DILocation(line: 3, scope: !8)