Change debug-info-for-profiling from a TargetOption to a function attribute.

[danielcdh]

Summary

LTO requires the debug-info-for-profiling to be a function attribute.

[ahatanak]

lib/CodeGen/AsmPrinter/DwarfDebug.cpp

1138

Is debug-info-for-profiling used to turn on and off debug info for profiling on a per-function basis? I'm not very familiar with this function, but it looks like HasDebugInfoForProfiling is initialized to false in the constructor and then it will always be true after beginFunction is called on a function that has attribute debug-info-for-profiling=true.

[mehdi_amini]

include/llvm/IR/Attributes.td

182

That'll be long in the IR, where there is already a long list, what about "prof-dbg-info" or something like that that would make sense?

lib/CodeGen/AsmPrinter/DwarfDebug.cpp

1138

Yep that seems broken to me. If foo has the attribute and not bar, we'll emit the profiling debug info for bar if foo is processed first.

[danielcdh]

lib/CodeGen/AsmPrinter/DwarfDebug.cpp

1138

The issue is that I cannot check for function's attributes in DwarfUnit::applySubprogramAttributes, any suggestions on how I can pass down this attribute to that function?

[mehdi_amini]

lib/CodeGen/AsmPrinter/DwarfDebug.cpp

1138

Why not do here HasDebugInfoForProfiling = MF->getFunction()->debugInfoForProfiling(); ?

[probinson]

Is there a reason to make this a function attribute rather than a flag carried in the metadata? Having something related to debug info as an attribute seems odd.

test/DebugInfo/Inputs/gmlt_profiling.ll

5

f2() does not appear in any checks and is not used anywhere else in the test. Why is it here?

7

f3() and f4() do not appear in any checks, why are they here?

14

Writing checks for dwarfdump output is tricky because you're really trying to match several attribute lines within the same DWARF entry. So here you want something like this:

CHECK: DW_TAG_subprogram
CHECK-NOT: {{DW_TAG|NULL}}
CHECK: DW_AT_name {{.*}} "f1"
CHECK-NEXT: DW_AT_decl_file
CHECK-NEXT: DW_AT_decl_line

This assumes that name/file/line appear in that exact sequence, but there are lots of debug-info tests with that kind of assumption. Unless/until we get a fancier debug-info matcher this is the kind of thing we have to do.

43

Generally we encourage people to remove attributes that aren't relevant or necessary to the test. Here, probably only "debug-info-for-profiling" is the relevant one? Removing the others helps clarify what the test is about.

[danielcdh]

lib/CodeGen/AsmPrinter/DwarfDebug.cpp

1138

Because the llvm::DwarfDebug::beginFunction is called first before llvm::DwarfUnit::applySubprogramAttributes are called.

E.g. you have f1, f2, f3

the call sequence is:
beginFunction(f1)
beginFunction(f2)
beginFunction(f3)
applySubprogramAttributes(subprogramof_f1)
applySubprogramAttributes(subprogramof_f2)
applySubprogramAttributes(subprogramof_f3)

The current logic is, if there is any function that has HasDebugInfoForProfiling=true, then all function will have it.

[probinson]

lib/CodeGen/AsmPrinter/DwarfDebug.cpp

1138

All the more reason to put it at module or CU level, rather than function level.

[mehdi_amini]

lib/CodeGen/AsmPrinter/DwarfDebug.cpp

1138

If the behavior you want is to have it enabled for the module, then yes like @probinson says a module level construct would make more sense.

I don't enough about -gmlt to know what we would expect if we have a.cpp and b.cpp and we build with LTO one with -g and the other one with -gmlt ?

[danielcdh]

change to use module flags.

[danielcdh]

lib/CodeGen/AsmPrinter/DwarfDebug.cpp

1138

Updated to use module flag for this.

test/DebugInfo/Inputs/gmlt_profiling.ll

14

Done, but the CHECK-NOT cannot be used because we have DW_AT_low_pc and DW_AT_high_pc in between.

[mehdi_amini]

lib/CodeGen/AsmPrinter/DwarfDebug.cpp

1138

Can you clarify what is the behavior in this case:

what we would expect if we have a.cpp and b.cpp and we build with LTO one with -g and the other one with -gmlt ?

[danielcdh]

lib/CodeGen/AsmPrinter/DwarfDebug.cpp

1138

I am not debug info expert, Eric may have more accurate answer.

My understanding is that one will have more debug info emitted, the other will only have line table emitted. What will happen in LTO?

[mehdi_amini]

lib/CodeGen/AsmPrinter/DwarfDebug.cpp

1138

I'm asking because I haven ming that of DebugInfoForProfiling will be enabled by -gmlt, but that may not be true? If so when/how is DebugInfoForProfiling set?

[danielcdh]

lib/CodeGen/AsmPrinter/DwarfDebug.cpp

1138

It will be set with -fdebug-info-for-profiling.

A follow-up cfe patch is in: https://reviews.llvm.org/D29205

[mehdi_amini]

lib/CodeGen/AsmPrinter/DwarfDebug.cpp

1138

Ok so back to my question:

what we would expect if we have a.cpp and b.cpp and we build with LTO one with -g and the other one with -fdebug-info-for-profiling? How does your module flag affect that?

[danielcdh]

lib/CodeGen/AsmPrinter/DwarfDebug.cpp

1138

-fdebug-info-for-profiling is orthogonal with -g/-gmlt. So I guess the question should be:

what we would expect if we have a.cpp and b.cpp and we build with LTO, a.cpp with -fdebug-info-for-profiling and b.cpp without the flag? How does your module flag affect that?

The answer is

• a.cpp will have the flag and thus all the logic guarded by this flag in backend will be executed.
• b.cpp will not have it and will not have related code executed.
• If some functions are imported from b.cpp to a.cpp, it will inherit the flag from a.cpp thus have related code executed.
• If some functions are imported from a.cpp to c.cpp, it will inherit the flag from b.cpp thus not have related code executed.

I guess this also applies to the cases that a.cpp is built with -g and b.cpp is built with -gmlt.

[mehdi_amini]

lib/CodeGen/AsmPrinter/DwarfDebug.cpp

1138

During Monolithic LTO, the two files are *merged*. There is a single CodeGen happening.

I'm still trying to figure out what is the impact of If some functions are imported from b.cpp to a.cpp, it will inherit the flag from a.cpp thus have related code executed, because I don't know enough about -fdebug-info-for-profiling.

I think I originally misread this comment:

// Under -gmlt, skip building the subprogram if there are no inlined
// subroutines inside it. But with -fdebug-info-for-profiling, the subprogram
// is still needed as we need its source location.

If I understand correctly, the module flag would make the debug info emission more conservative. Does it mean that adding -fdebug-info-for-profiling with -g does not have any effect on the Dwarf emission? It is only in effect with DICompileUnit::LineTablesOnly?

[danielcdh]

lib/CodeGen/AsmPrinter/DwarfDebug.cpp

1138

-fdebug-info-for-profiling has the following implication:

1. emit extra subprogram info (e.g. decl_line) even with -gmlt
2. emit discriminator and encode optimization effects to discriminator.

For #1, -g also emits these extra info, thus it only applies to -gmlt
For #2, which is under review in https://reviews.llvm.org/D26420, it applies to both -g and -gmlt builds.

[mehdi_amini]

lib/CodeGen/AsmPrinter/DwarfDebug.cpp

1138

Thanks for the explanation!
With this I'm fine with the module flag.

If @probinson does not have any other comment that LGTM.

[probinson]

Regarding the mixed-mode LTO question, my understanding is that if we have a module-level flag then it would apply to everything in the merged module. The merged module will still have debug info organized per original compilation unit. So, if we have a per-CU flag and compiled flag-on.cpp and flag-off.cpp, then functions from flag-on.cpp would get the extra info and functions from flag-off.cpp would not, with the caveat that if you inline a function across compilation units, then the flag from the CU for the caller would apply.

I believe we have a module flag here, so the entire module would be treated as if -fdebug-info-for-profiling had been turned on for all CUs.

(Did I get that right?)

test/DebugInfo/Inputs/gmlt_profiling.ll

14

The CHECK-NOT should not match a DW_AT line. You need it to ensure that the attributes belong to the same TAG that you found.

[danielcdh]

After a lengthy discussion with @dblaikie (Thanks David for the input), let me add some more context to this patch.

• What is the impact of adding -fdebug-info-for-profiling
  • It will not affect the generated code
  • It will increase the debug info size in -gmlt by ~17%
  • It will not increase the debug info size in -g binary
  • The compile time change should be negligible

• What we use a binary built with out -fdebug-info-for-profiling to collect profile
  • The profile will be inaccurate and will yield sub-optimal performance when used to drive SamplePGO

• What is the motivating example that you want to compile some sources with -fdebug-info-for-profiling and some without
  • If the debug info size is a concern for -gmlt binary, then one would want to only enable this flag for sources that is performance-critical

[danielcdh]

In D29203#658981, @probinson wrote:

Regarding the mixed-mode LTO question, my understanding is that if we have a module-level flag then it would apply to everything in the merged module. The merged module will still have debug info organized per original compilation unit. So, if we have a per-CU flag and compiled flag-on.cpp and flag-off.cpp, then functions from flag-on.cpp would get the extra info and functions from flag-off.cpp would not, with the caveat that if you inline a function across compilation units, then the flag from the CU for the caller would apply.

I believe we have a module flag here, so the entire module would be treated as if -fdebug-info-for-profiling had been turned on for all CUs.

I think you are right. If we always emit this module flag (with value 0 or 1), when there are some CUs built with this flag, and some CUs without, in LTO, it will emit a warning and turn this flag on for all CUs.

Dehao

(Did I get that right?)

[mehdi_amini]

In D29203#658997, @danielcdh wrote:

• What is the motivating example that you want to compile some sources with -fdebug-info-for-profiling and some without
  • If the debug info size is a concern for -gmlt binary, then one would want to only enable this flag for sources that is performance-critical

This is an argument *against* a module flag.

[danielcdh]

In D29203#659019, @mehdi_amini wrote:

In D29203#658997, @danielcdh wrote:

• What is the motivating example that you want to compile some sources with -fdebug-info-for-profiling and some without
  • If the debug info size is a concern for -gmlt binary, then one would want to only enable this flag for sources that is performance-critical

This is an argument *against* a module flag.

Right ;-) I think I need to raise the point before close the patch.

But my opinion is that this use cases (if any) would be rare because:

• 17% seem small, but people may have other opinions
• adding per-CU flag is manual and tedious
• per-CU flag may need to change as new source coming in/old source change that updates the hot CU distribution

That being said, I would think it's better to force this flag in LTO when mixed flag situation happens. But will let upstream decide if this would be a feature or a bug.

Thanks,
Dehao

[danielcdh]

Change to use DICompileUnit to pass down the flag.

[probinson]

test/DebugInfo/Inputs/gmlt_profiling.ll

8

The CHECK-NOT needs to go before DW_AT_name.
You are using CHECK-NEXT to guarantee that decl_file and decl_line are in the same tag as DW_AT_name.

[dblaikie]

include/llvm/IR/DebugInfoMetadata.h

1140–1142 ↗

(On Diff #86117)

I don't think this accessor is needed

lib/CodeGen/AsmPrinter/DwarfDebug.h

266–268

Presumably this (& the accessor below) can be removed now?

lib/IR/Module.cpp

468–475 ↗

(On Diff #86117)

Presumably this should go away now that it's in the CU metadata.

test/DebugInfo/Generic/gmlt.test

2

This line should probably be in gmlt.ll (both gmlt.ll and gmlt_profiling.ll would move from test/DebugInfo/Inputs to test/DebugInfo/Generic)

3

This line should probably be in gmlt_profiling.ll

[danielcdh]

update also remove TargetOption.DebugInfoForProfiling.

[aprantl]

I didn't see a binary bitcode upgrade testcase — could you please add one?

[aprantl]

include/llvm/IR/DIBuilder.h

107 ↗

(On Diff #86131)

Missing doxygen for the new(er) flag(s).

[aprantl]

It might also be a good idea to document the purpose of the flag in SourceLevelDebugging.rst,

[danielcdh]

Add bitcode test.

[danielcdh]

update doxygen.

[danielcdh]

In D29203#659334, @aprantl wrote:

It might also be a good idea to document the purpose of the flag in SourceLevelDebugging.rst,

Could you help suggest which section I should add related doc? I think it would be good to add to the doc that introduces different debug level, but seems no such content exists in the current doc.

[aprantl]

That document clearly needs a some love :-)
I would suggest adding a new Compile Unit section to either of the two Debugging information format sections (which should be merged) and adding a stub about global (compile-unit-wide) flags that influence the DWARF/CodeView debug info generator.

[danielcdh]

In D29203#659527, @aprantl wrote:

That document clearly needs a some love :-)
I would suggest adding a new Compile Unit section to either of the two Debugging information format sections (which should be merged) and adding a stub about global (compile-unit-wide) flags that influence the DWARF/CodeView debug info generator.

Sounds reasonable. But that seems quite some extra work that is outside the scope of this patch. Shall we start a separate thread to improve the documentation of the debug info?

[aprantl]

Works for me.

[aprantl]

Commented on bitcode test

test/Bitcode/upgrade-debug-info-for-profiling.ll

4 ↗

(On Diff #86139)

This probably isn't necessary.

13 ↗

(On Diff #86139)

Perhaps I'm confused about what this is testing*, but shouldn't the default be debugInfoForProfiling: false?

*) I was expecting a DICompilieUnit produced by today's trunk without a bitcode record for the new flag, so we can verify that the old bitcode format is updated correctly.

[danielcdh]

update upgrading test

[danielcdh]

test/Bitcode/upgrade-debug-info-for-profiling.ll

13 ↗

(On Diff #86139)

Not sure if I understand what to test in this upgrade test.

What I did here:

1. build the .ll file with the current trunk without this patch to produce the .bc file
2. check "debugInfoForProfiling: true" does *not* exists in the llvm-dis output.

Am I doing the right thing?

[aprantl]

I added one comment to the testcase, otherwise this is fine now.

test/Bitcode/upgrade-debug-info-for-profiling.ll

8 ↗

(On Diff #86288)

Ah I didn't see the -NOT.
It is better to write this as
CHECK: DICompileUnit(language: DW_LANG_C99, file: !{{[0-9]+]], emissionKind: FullDebug)
otherwise /bin/true would also pass this test.

[danielcdh]

update

[dblaikie]

Looks good

[danielcdh]

update a test to point to the correct location.

[dlj]

test/DebugInfo/Generic/gmlt.test

2

Moving this file to Generic/ means that other tests (notably, under X86/) now use files not within their Inputs, or within their parents' Inputs. Was that the intent of this comment?

[danielcdh]

This change was addressing one of the review comments.

test/DebugInfo/X86/gmlt.test do now depends on the input file from test/DebugInfo/Generic/gmlt.ll. If this is an issue, I can send another patch to move gmlt.ll back to test/DebugInfo/Input and add test/DebugInfo/Generic/gmlt.test back.

[danielcdh]

updated in r293852

[danielcdh]

I should have discovered the breaking x86 version of the test earlier...

Thanks for the reviews!

include/llvm/IR/Attributes.td

 def ZExt : EnumAttr<"zeroext">;
 
 /// Target-independent string attributes.
 def LessPreciseFPMAD : StrBoolAttr<"less-precise-fpmad">;
 def NoInfsFPMath : StrBoolAttr<"no-infs-fp-math">;
 def NoNansFPMath : StrBoolAttr<"no-nans-fp-math">;
 def UnsafeFPMath : StrBoolAttr<"unsafe-fp-math">;
 def NoJumpTables : StrBoolAttr<"no-jump-tables">;
+def DebugInfoForProfiling : StrBoolAttr<"debug-info-for-profiling">;
 
 class CompatRule<string F> {
   // The name of the function called to check the attribute of the caller and
   // callee and decide whether inlining should be allowed. The function's
   // signature must match "bool(const Function&, const Function &)", where the
   // first parameter is the reference to the caller and the second parameter is
   // the reference to the callee. It must return false if the attributes of the
   // caller and callee are incompatible, and true otherwise.

 }
 
 def : MergeRule<"setAND<LessPreciseFPMADAttr>">;
 def : MergeRule<"setAND<NoInfsFPMathAttr>">;
 def : MergeRule<"setAND<NoNansFPMathAttr>">;
 def : MergeRule<"setAND<UnsafeFPMathAttr>">;
 def : MergeRule<"setOR<NoImplicitFloatAttr>">;
 def : MergeRule<"setOR<NoJumpTablesAttr>">;
+def : MergeRule<"setOR<DebugInfoForProfilingAttr>">;
 def : MergeRule<"adjustCallerSSPLevel">;

include/llvm/IR/Function.h

public:
   /// Optimize this function for minimum size (-Oz).
   bool optForMinSize() const { return hasFnAttribute(Attribute::MinSize); }
 
   /// Optimize this function for size (-Os) or minimum size (-Oz).
   bool optForSize() const {
     return hasFnAttribute(Attribute::OptimizeForSize) || optForMinSize();
   }
 
+  /// Emit debug info for profiling.
+  bool debugInfoForProfiling() const {
+    return getFnAttribute("debug-info-for-profiling").getValueAsString() == "true";
+  }
+
   /// copyAttributesFrom - copy all additional attributes (those not needed to
   /// create a Function) from the Function Src to this one.
   void copyAttributesFrom(const GlobalValue *Src) override;
 
   /// deleteBody - This method deletes the body of the function, and converts
   /// the linkage to external.
   ///
   void deleteBody() {

lib/CodeGen/AsmPrinter/DwarfDebug.h

class DwarfDebug : public DebugHandlerBase {
   bool UseAllLinkageNames;
 
   /// DWARF5 Experimental Options
   /// @{
   bool HasDwarfAccelTables;
   bool HasAppleExtensionAttributes;
   bool HasSplitDwarf;
 
+  /// Emit debug info for profiling
+  bool HasDebugInfoForProfiling;
+
   /// Separated Dwarf Variables
   /// In general these will all be for bits that are left in the
   /// original object file, rather than things that are meant
   /// to be in the .dwo sections.
 
   /// Holder for the skeleton information.
   DwarfFile SkeletonHolder;
 
public:
   bool useAppleExtensionAttributes() const {
     return HasAppleExtensionAttributes;
   }
 
   /// Returns whether or not to change the current debug info for the
   /// split dwarf proposal support.
   bool useSplitDwarf() const { return HasSplitDwarf; }
 
+  /// Returns whether or not to emit debug info for profiling.
+  bool useDebugInfoForProfiling() const { return HasDebugInfoForProfiling; }
+
   /// Returns the Dwarf Version.
   uint16_t getDwarfVersion() const;
 
   /// Returns the previous CU that was being updated
   const DwarfCompileUnit *getPrevCU() const { return PrevCU; }
   void setPrevCU(const DwarfCompileUnit *PrevCU) { this->PrevCU = PrevCU; }
 
   /// Returns the entries for the .debug_loc section.

lib/CodeGen/AsmPrinter/DwarfDebug.cpp

DwarfDebug::DwarfDebug(AsmPrinter *A, Module *M)
   HasAppleExtensionAttributes = tuneForLLDB();
 
   // Handle split DWARF. Off by default for now.
   if (SplitDwarf == Default)
     HasSplitDwarf = false;
   else
     HasSplitDwarf = SplitDwarf == Enable;
 
+  HasDebugInfoForProfiling = false;
+
   // Pubnames/pubtypes on by default for GDB.
   if (DwarfPubSections == Default)
     HasDwarfPubSections = tuneForGDB();
   else
     HasDwarfPubSections = DwarfPubSections == Enable;
 
   // SCE defaults to linkage names only for abstract subprograms.
   if (DwarfLinkageNames == DefaultLinkageNames)
static DebugLoc findPrologueEndLoc(const MachineFunction *MF) {
   return DebugLoc();
 }
 
 // Gather pre-function debug information.  Assumes being called immediately
 // after the function entry point has been emitted.
 void DwarfDebug::beginFunction(const MachineFunction *MF) {
   CurFn = MF;
 
+  if (MF->getFunction()->debugInfoForProfiling())
+    HasDebugInfoForProfiling=true;
+
   // If there's no debug info for the function we're not going to do anything.
   if (!MMI->hasDebugInfo())
     return;
 
   auto DI = MF->getFunction()->getSubprogram();
   if (!DI)
     return;
 
void DwarfDebug::endFunction(const MachineFunction *MF) {
   collectVariableInfo(TheCU, SP, ProcessedVars);
 
   // Add the range of this function to the list of ranges for the CU.
   TheCU.addRange(RangeSpan(Asm->getFunctionBegin(), Asm->getFunctionEnd()));
 
   // Under -gmlt, skip building the subprogram if there are no inlined
   // subroutines inside it. But with -fdebug-info-for-profiling, the subprogram
   // is still needed as we need its source location.
-  if (!Asm->TM.Options.DebugInfoForProfiling &&
+  if (!MF->getFunction()->debugInfoForProfiling() &&
       TheCU.getCUNode()->getEmissionKind() == DICompileUnit::LineTablesOnly &&
       LScopes.getAbstractScopesList().empty() && !IsDarwin) {
     assert(InfoHolder.getScopeVariables().empty());
     assert(DbgValues.empty());
     // FIXME: This wouldn't be true in LTO with a -g (with inlining) CU followed
     // by a -gmlt CU. Add a test and remove this assertion.
     assert(AbstractVariables.empty());
     PrevLabel = nullptr;

lib/CodeGen/AsmPrinter/DwarfUnit.cpp

bool DwarfUnit::applySubprogramDefinitionAttributes(const DISubprogram *SP,
   return true;
 }
 
 void DwarfUnit::applySubprogramAttributes(const DISubprogram *SP, DIE &SPDie,
                                           bool SkipSPAttributes) {
   // If -fdebug-info-for-profiling is enabled, need to emit the subprogram
   // and its source location.
   bool SkipSPSourceLocation = SkipSPAttributes &&
-                              !Asm->TM.Options.DebugInfoForProfiling;
+                              !DD->useDebugInfoForProfiling();
   if (!SkipSPSourceLocation)
     if (applySubprogramDefinitionAttributes(SP, SPDie))
       return;
 
   // Constructors and operators for anonymous aggregates do not have names.
   if (!SP->getName().empty())
     addString(SPDie, dwarf::DW_AT_name, SP->getName());
 

test/DebugInfo/Generic/gmlt.test

 ; REQUIRES: object-emission
 ; RUN: %llc_dwarf -O0 -filetype=obj < %S/../Inputs/gmlt.ll | llvm-dwarfdump - | FileCheck %S/../Inputs/gmlt.ll
-; RUN: %llc_dwarf -O0 -filetype=obj -debug-info-for-profiling < %S/../Inputs/gmlt.ll | llvm-dwarfdump - | FileCheck %S/../Inputs/gmlt.ll --check-prefixes=PROFILING
+; RUN: %llc_dwarf -O0 -filetype=obj < %S/../Inputs/gmlt_profiling.ll | llvm-dwarfdump - | FileCheck %S/../Inputs/gmlt_profiling.ll
 
 ; There's a darwin specific test in X86/gmlt, so it's okay to XFAIL this here.
 ; XFAIL: darwin

test/DebugInfo/Inputs/gmlt.ll

 ; Make sure we don't have any other subprograms here (subprograms with no
 ; inlined subroutines are omitted by design to save space)
 
 ; CHECK-NOT: {{DW_TAG|DW_AT}}
 ; CHECK: NULL
 ; CHECK-NOT: {{DW_TAG|DW_AT}}
 ; CHECK: NULL
 
-; PROFILING: DW_TAG_subprogram
-; PROFILING: DW_AT_name {{.*}} "f1"
-; With -debug-info-for-profiling, we need to emit decl_file a-nd decl_line
-; of the subprogram.
-; PROFILING: DW_AT_decl_file
-; PROFILING: DW_AT_decl_line
-
 ; CHECK: .debug_ranges contents:
 
 ; ... some addresses (depends on platform (such as platforms with function
 ; reordering in the linker), and looks wonky on platforms with zero values
 ; written in relocation places (dumper needs to be fixed to read the
 ; relocations rather than interpret that as the end of a range list))
 
 ; CHECK: 00000000 <End of list>

test/DebugInfo/Inputs/gmlt_profiling.ll

+; REQUIRES: object-emission
+
+; Generated from the following source compiled with clang++ -gmlt:
+; void f1() {}
+; void __attribute__((section("__TEXT,__bar"))) f2() {}
+; void __attribute__((always_inline)) f3() { f1(); }
+; void f4() { f3(); }
+
+; CHECK: DW_TAG_subprogram
+; CHECK: DW_AT_name {{.*}} "f1"
+; With debug-info-for-profiling attribute, we need to emit decl_file and
+; decl_line of the subprogram.
+; CHECK: DW_AT_decl_file
+; CHECK: DW_AT_decl_line
+
+; Function Attrs: nounwind uwtable
+define void @_Z2f1v() #0 !dbg !4 {
+entry:
+  ret void, !dbg !13
+}
+
+; Function Attrs: nounwind uwtable
+define void @_Z2f2v() #0 section "__TEXT,__bar" !dbg !7 {
+entry:
+  ret void, !dbg !14
+}
+
+; Function Attrs: alwaysinline nounwind uwtable
+define void @_Z2f3v() #1 !dbg !8 {
+entry:
+  call void @_Z2f1v(), !dbg !15
+  ret void, !dbg !16
+}
+
+; Function Attrs: nounwind uwtable
+define void @_Z2f4v() #0 !dbg !9 {
+entry:
+  call void @_Z2f1v() #2, !dbg !17
+  ret void, !dbg !19
+}
+
+attributes #0 = { nounwind uwtable "debug-info-for-profiling"="true" "less-precise-fpmad"="false" "no-frame-pointer-elim"="true" "no-frame-pointer-elim-non-leaf" "no-infs-fp-math"="false" "no-nans-fp-math"="false" "stack-protector-buffer-size"="8" "unsafe-fp-math"="false" "use-soft-float"="false" }
+attributes #1 = { alwaysinline nounwind uwtable "less-precise-fpmad"="false" "no-frame-pointer-elim"="true" "no-frame-pointer-elim-non-leaf" "no-infs-fp-math"="false" "no-nans-fp-math"="false" "stack-protector-buffer-size"="8" "unsafe-fp-math"="false" "use-soft-float"="false" }
+attributes #2 = { nounwind }
+
+!llvm.dbg.cu = !{!0}
+!llvm.module.flags = !{!10, !11}
+!llvm.ident = !{!12}
+
+!0 = distinct !DICompileUnit(language: DW_LANG_C_plus_plus, producer: "clang version 3.6.0 ", isOptimized: false, emissionKind: LineTablesOnly, file: !1, enums: !2, retainedTypes: !2, globals: !2, imports: !2)
+!1 = !DIFile(filename: "gmlt.cpp", directory: "/tmp/dbginfo")
+!2 = !{}
+!4 = distinct !DISubprogram(name: "f1", line: 1, isLocal: false, isDefinition: true, virtualIndex: 6, flags: DIFlagPrototyped, isOptimized: false, unit: !0, scopeLine: 1, file: !1, scope: !5, type: !6, variables: !2)
+!5 = !DIFile(filename: "gmlt.cpp", directory: "/tmp/dbginfo")
+!6 = !DISubroutineType(types: !2)
+!7 = distinct !DISubprogram(name: "f2", line: 2, isLocal: false, isDefinition: true, virtualIndex: 6, flags: DIFlagPrototyped, isOptimized: false, unit: !0, scopeLine: 2, file: !1, scope: !5, type: !6, variables: !2)
+!8 = distinct !DISubprogram(name: "f3", line: 3, isLocal: false, isDefinition: true, virtualIndex: 6, flags: DIFlagPrototyped, isOptimized: false, unit: !0, scopeLine: 3, file: !1, scope: !5, type: !6, variables: !2)
+!9 = distinct !DISubprogram(name: "f4", line: 4, isLocal: false, isDefinition: true, virtualIndex: 6, flags: DIFlagPrototyped, isOptimized: false, unit: !0, scopeLine: 4, file: !1, scope: !5, type: !6, variables: !2)
+!10 = !{i32 2, !"Dwarf Version", i32 4}
+!11 = !{i32 2, !"Debug Info Version", i32 3}
+!12 = !{!"clang version 3.6.0 "}
+!13 = !DILocation(line: 1, column: 12, scope: !4)
+!14 = !DILocation(line: 2, column: 53, scope: !7)
+!15 = !DILocation(line: 3, column: 44, scope: !8)
+!16 = !DILocation(line: 3, column: 50, scope: !8)
+!17 = !DILocation(line: 3, column: 44, scope: !8, inlinedAt: !18)
+!18 = !DILocation(line: 4, column: 13, scope: !9)
+!19 = !DILocation(line: 4, column: 19, scope: !9)