[DebugInfo] Add option to disable inline line tables.

[akhuang]

Summary

This adds a clang option to disable inline line tables. When it is used,
the inliner uses the call site as the location of the inlined function instead of
marking it as an inline location with the function location.

See https://bugs.llvm.org/show_bug.cgi?id=42344

[rnk]

+ other debug info people

llvm/docs/LangRef.rst

1444

This is a string attribute, so it should have quotes around it.

llvm/lib/Transforms/Utils/InlineFunction.cpp

1439

Let's check hasFnAttribute out of the loop so we aren't doing string hash lookups in a loop.

1443–1456

Let's actually try to reuse this !CalleeHasDebugInfo code path when this function attribute is present. They should do the same thing.

[dblaikie]

As per the bug - I'm not super inclined towards a function attribute here (& even if it's going to be an inliner rather than debug info generation/backend thing (which I'm more on the fence about - think I'm happy with either direction there, really) - I'd still be inclined towards it living in the DICompileUnit with other debug info things, rather than a function attribute). But happy to hear what other folks (especially the usual debug info cabal - @aprantl @probinson @JDevlieghere etc) think.

[akhuang]

• Address comments

[jmorse]

Looks good, although I'm not familiar enough with frontend things to approve IMO.

Using a function attribute seems fine and appropriate too -- although CU flags is another thing I'm unfamiliar with, so I can't really offer an opinion.

[aprantl]

I don't think the implementation is correct, see inline comments.

clang/include/clang/Driver/Options.td

1963

As a DWARF person, this option name is a little confusing since in DWARF inline info is part of debug info, not the line table, but few end-users would actually know. I would probably have called it -gno-inline-info or -gno-inlined-functions. I don't have strong feelings about it though.

llvm/docs/LangRef.rst

1445

Same comment for the attribute.

llvm/lib/Transforms/Utils/InlineFunction.cpp

1444

This will probably cause some IR Verifier failures and very confusing debug info when inlining dbg.value intrinsics. The correct thing to do here is probably to assign line 0 to the inlined instructions and remove all debug info intrinsics. Otherwise the inlined variables will show up in the parent frame, which will screw up debugging.

[aprantl]

llvm/lib/Transforms/Utils/InlineFunction.cpp

1444

cf. getMergedLocation() for how to do this.

[aprantl]

There also needs to be a IR-based test for the inliner change.

[rnk]

clang/include/clang/Driver/Options.td

1963

The other two options we have that control this stuff are -gmlt / -gline-tables-only. gmlt stands for "g minimal line tables". So, our command line interface talks about "line tables" already, and IMO we should stick with it, even if it's not really a table after all.

And, technically, this option will greatly affect the .debug_line section. The inlined source locations are normally present in .debug_line, and this change suppresses them. Instead, the debugger will appear to be stopped at the inlined call site.

llvm/docs/LangRef.rst

1445

Maybe we could use more precise wording rather than talking about tables. Maybe we should describe what happens from the user perspective, something like:

When this attribute is present and set to true, the inliner will discard source locations while inlining code into the current function. Instead, the source location of the call site will be used for all inlined code. Breakpoints set on code that was inlined into the current function will not fire during the execution of the inlined call sites. If the debugger stops inside an inlined call site, it will appear to be stopped at the outermost inlined call site.

llvm/lib/Transforms/Utils/InlineFunction.cpp

1443–1456

This suggestion makes less sense in light of the need to remove variable information. Use your best judgement.

1444

Ah, yes, we should erase all debug info for inlined variables while inlining in this mode.

[akhuang]

-Remove intrinsics debug info
-Add inliner test
-Add to function attribute description

[rnk]

llvm/lib/Transforms/Utils/InlineFunction.cpp

1427

Each of these inherit from DbgVariableIntrinsic, so you should be able to dyn_cast to that, and handle them all with one if.

llvm/test/Transforms/Inline/no-inline-line-tables.ll

32

Test looks good

[akhuang]

• Remove extra ifs.

[rnk]

I guess the commit message shouldn't say "[CodeView] Add option to disable inline line tables." It's really an option for all debug info. You could put "[DebugInfo]" on there, or just drop the tag.

[aprantl]

I would still prefer no-inline-info or no-inline-debuginfo over no-inline-linetables and a line 0 location for the inlined instructions. Other than that the patch is now safe.

llvm/lib/Transforms/Utils/InlineFunction.cpp

1431

I still think an artificial (line 0) location would be less misleading for debuggers, profilers, and optimization remarks.

[akhuang]

Fix code so that -gno-inline-line-tables works when not codeview

[akhuang]

• Set location to line 0 with getMergedLocation

[akhuang]

Fixed to remove all DbgInfoIntrinsics instead of just DbgVariableIntrinsics

[rnk]

Based on what we learned in https://llvm.org/PR43530, I think we still want to use the location of the call site and not line zero. :(

llvm/lib/Transforms/Utils/InlineFunction.cpp

1431

That will cause problems for us in practice. There's discussion about this in D68747. Since that change, we treat line zero the same as "no location". If there are no locations in a basic block, then the whole block inherits the line number from the block layout predecessor, which could be unrelated. Keeping the inlined call site location gives us the highest likelihood that "step over" will stop at the next statement. Widely applying line zero to entire basic blocks will put us in that situation more often. We could certainly write a pass to backfill better source locations, but it seems preferable to not put ourselves in that position in the first place.

However, the effect you mention on profilers and optimization remarks is real and concerning. Users should have the power to work around it by removing the flag that applies this attribute, which makes me feel like we should go forward with this as is. If this develops into a real usability problem, we can leave the attribute as is and move the implementation into the backend.

[akhuang]

• Fixes for DbgInfoIntrinsic type and change test cmd

Reverted the line 0 change - I wasn't sure if it would be an issue since
the debugger doesn't step through those lines.

[rnk]

llvm/lib/Transforms/Utils/InlineFunction.cpp

1428

Will this work if the dbg.value is the first instruction of a basic block? I'd expect eraseFromParent to return a new iterator pointing to FI->begin(), then operator-- to back up to "before begin", which would probably crash or assert. This would make a good test case and shouldn't be too hard. You can try inlining foo in this example:

void bar();
int foo(bool cond, int x) {
  if (cond) {
    x = 42; // should set up a dbg.value at BB start
    bar(); // block select formation
  }
  return x;
}

[aprantl]

Since that change, we treat line zero the same as "no location". If there are no locations in a basic block, then the whole block inherits the line number from the block layout predecessor, which could be unrelated. Keeping the inlined call site location gives us the highest likelihood that "step over" will stop at the next statement.

Who is "we" in this context? The CodeView backend?
As far as DWARF is concerned (and LLVM mostly inherits the DWARF semantics) line 0 is well-defined and means compiler-generated code or otherwise no unambiguous source location. DWARF-based debuggers know to skip over instructions with line 0.

Is the problem that CodeView doesn't have this concept, or does the Windows debugger no know how to deal with it (or both)?

I'm feeling rather strongly that that LLVM should not be emitting wrong debug info to work around bugs in a debugger. I understand that sometimes this isn't possible because we don't control the consumers. The correct thing to do here is to guard the workaround by a debugger tuning flag. For DWARF, we do want line 0 here.

[dblaikie]

In D67723#1708671, @aprantl wrote:

Since that change, we treat line zero the same as "no location". If there are no locations in a basic block, then the whole block inherits the line number from the block layout predecessor, which could be unrelated. Keeping the inlined call site location gives us the highest likelihood that "step over" will stop at the next statement.

Who is "we" in this context? The CodeView backend?
As far as DWARF is concerned (and LLVM mostly inherits the DWARF semantics) line 0 is well-defined and means compiler-generated code or otherwise no unambiguous source location. DWARF-based debuggers know to skip over instructions with line 0.

Is the problem that CodeView doesn't have this concept, or does the Windows debugger no know how to deal with it (or both)?

I'm feeling rather strongly that that LLVM should not be emitting wrong debug info to work around bugs in a debugger. I understand that sometimes this isn't possible because we don't control the consumers. The correct thing to do here is to guard the workaround by a debugger tuning flag. For DWARF, we do want line 0 here.

(+1 to all that, FWIW)

Though I think in this case since it's got to be handled during the transformation (rather than as an after the fact choice at debug-info-emission time) it might not be practical to guard by a debugger tuning flag. It could/should be guarded though, but may just have to be guarded by the format (not that we have any other debuggers consuming CodeView anyway, so I think it's sufficient here).

[rnk]

In D67723#1708671, @aprantl wrote:

Who is "we" in this context? The CodeView backend?

Yes, the CodeView backend, sorry for the ambiguity.

As far as DWARF is concerned (and LLVM mostly inherits the DWARF semantics) line 0 is well-defined and means compiler-generated code or otherwise no unambiguous source location. DWARF-based debuggers know to skip over instructions with line 0.

Is the problem that CodeView doesn't have this concept, or does the Windows debugger no know how to deal with it (or both)?

Visual Studio in particular has been reported to have problems with line zero. It seems to treat it as some kind of error condition (no line available), and kicks the user over to the assembly view.

I'm feeling rather strongly that that LLVM should not be emitting wrong debug info to work around bugs in a debugger. I understand that sometimes this isn't possible because we don't control the consumers. The correct thing to do here is to guard the workaround by a debugger tuning flag. For DWARF, we do want line 0 here.

I don't think we want to emit line zero here. The use case for this flag is to allow the user to ask the compiler to attribute code from inlined call sites to the call site itself. Maybe the user doesn't want to see the details of push_back.

I actually went ahead and experimented with how gdb handles line zero. I compiled the following program like so:

$ cat t.cpp
volatile int x;
static inline void foo() {
  ++x;
  ++x;
}
int main() {
  ++x;
  foo();
  ++x;
  foo();
  ++x;
  return x;
}
$ clang -g -O2 t.cpp -S -emit-llvm -o t.ll
$ sed -e 's/DILocation.line:.*column:.*, scope\(.*inlinedAt: .*\))/DILocation(line: 0, column: 0, scope\1)/' -i t.ll
$ clang -g t.ll -o t.exe
$ gdb --args t.exe
...

When I step through main with s in gdb, it stops on the ++x lines, and skips the foo() lines completely. I don't think that's the desired behavior, the desired behavior is to treat the body of foo as a single line.

To give more context, back in 2013, @probinson asked if we should add a similar feature here:
http://lists.llvm.org/pipermail/cfe-dev/2013-November/033765.html
This was around the time that inlinedAt locations were being sorted out, I think. His proposed name for this flag was -gno-inlined-scopes. I believe nothing ever came of that discussion, and we continued on our way until today in 2019, when one of our users requested a similar feature. I vaguely recalled the discussion from 2013, but I had forgotten the details, so I figured that it might be a generally useful feature that others would appreciate. So, I suggested that @akhuang add a real flag for it, and that it should work for DWARF and CodeView. That's part of why I figured it would be good to implement it in the inliner, so we don't have to do the work twice.

Given the behavior of gdb shown above, I don't think either set of users, Chromium developers or Sony licensees, have a use case for a flag that applies line zero to inlined functions. I don't think that's what they are asking for. Paul outlined what users actually asked for back then here:
http://lists.llvm.org/pipermail/cfe-dev/2013-November/033782.html

I think users are asking for a flag that attributes the code that the inliner clones to the call site. And, I can't see any reason not to give it to them. Does that seem reasonable?

[akhuang]

Address comment about bad decrementing iterator.

[probinson]

Apologies for missing this until now. Our email system keeps dropping stuff sent by Phabricator.

FTR, since @rnk has mentioned my years-ago writings, what Sony has internally nowadays is a little different than what I said back then. We have an option spelled -gno-inlined-scopes which is slightly tricky to describe precisely, but the intent is that for debug-info purposes, certain functions appear to be empty. That is, the declaration is still emitted (which is different from nodebug) but the generated IR has no source locations.

We implement this in CodeGenFunction::GenerateCode, rather than down in LLVM. We found that the in-LLVM implementation would affect exactly those functions that were actually inlined by the optimizer, rather than those that had some kind of "inline me" indication in the source. This caught too many cases where they compiler inlined a function because of a cost heuristic rather than a source indication, and made the set of functions with no source locations somewhat unpredictable.

What is an "inline me" indication? The always_inline attribute, the inline keyword, or a class method whose definition is in-class.

Which functions are affected? Everything with always_inline regardless of optimization level, and also anything to which optimization applies and is marked inline or is defined in-class. ("Optimization applies" means compiling at -O1 or higher, and the function does not have OptimizeNoneAttr.)

This might all sound overly complicated, but after (I think) three attempts, it appears to filter out the set of functions that can be considered too small to bother with, and/or well-debugged and unlikely to be the cause of a problem, and of course everything in STL which by nature pretty much all has to have in-class definitions. It's a heuristic that is (at least to an extent) under the control of the programmer, and is a rule based strictly on source annotations and command-line options, rather than arbitrary choices made by the compiler (which possibly vary from build to build).

I haven't taken the time to read through all the prior comments and re-read the PR etc, but I did want to report what it is that we actually do now, and which seems to keep the users-who-care happy enough over the past few years.

[rnk]

In D67723#1710134, @probinson wrote:

FTR, since @rnk has mentioned my years-ago writings, what Sony has internally nowadays is a little different than what I said back then. We have an option spelled -gno-inlined-scopes which is slightly tricky to describe precisely, but the intent is that for debug-info purposes, certain functions appear to be empty. That is, the declaration is still emitted (which is different from nodebug) but the generated IR has no source locations.

Thanks for the info. That's interesting, and in the end I suppose it's pretty different from the behavior we had in mind for this flag.

---

I chatted offline with @dblaikie and he suggested perhaps it would be better to motivate this flag as one of the many existing knobs we have for controlling the volume of debug info produced by the debugger. We already have two major examples of this:

• -gline-tables-only / -gmlt / -g1
• -flimit-debug / -fno-standalone-debug

This flag exists to give the user the ability to produce even less debug info, if that debug info seems to be putting pressure on the tools downstream: the linker or the debugger. We are motivated by one tool in particular at the moment, but if we're going to take the time to add a knob, we might as well make it work for DWARF. If the user cares enough to find this flag, it seems more user friendly to make it behave the same rather than making it format-dependent.

@aprantl hit accept on a previous diff, but Amy changed the line zero behavior after that, so I just wanted to reconfirm that the current behavior is OK.

[aprantl]

In D67723#1717416, @rnk wrote:

In D67723#1710134, @probinson wrote:

FTR, since @rnk has mentioned my years-ago writings, what Sony has internally nowadays is a little different than what I said back then. We have an option spelled -gno-inlined-scopes which is slightly tricky to describe precisely, but the intent is that for debug-info purposes, certain functions appear to be empty. That is, the declaration is still emitted (which is different from nodebug) but the generated IR has no source locations.

Thanks for the info. That's interesting, and in the end I suppose it's pretty different from the behavior we had in mind for this flag.

---

I chatted offline with @dblaikie and he suggested perhaps it would be better to motivate this flag as one of the many existing knobs we have for controlling the volume of debug info produced by the debugger. We already have two major examples of this:

• -gline-tables-only / -gmlt / -g1
• -flimit-debug / -fno-standalone-debug

This flag exists to give the user the ability to produce even less debug info, if that debug info seems to be putting pressure on the tools downstream: the linker or the debugger.

I agree that it would make sense to have a -ginline-info-threshold=<#insns> or -gno-small-inline-functions with a hardcoded threshold to implement the feature Paul described, and this patch seems to be a step in that direction, with the threshold being hardcoded to 0.

We are motivated by one tool in particular at the moment, but if we're going to take the time to add a knob, we might as well make it work for DWARF.

Here you got me confused: When I read "we might as well make it work for DWARF", I read that as "we should emit the inlined instructions with line 0 under a DWARF debugger tuning". But that reading seems to to contradict your next sentence:

If the user cares enough to find this flag, it seems more user friendly to make it behave the same rather than making it format-dependent.

Can you clarify?

[rnk]

In D67723#1717468, @aprantl wrote:

I agree that it would make sense to have a -ginline-info-threshold=<#insns> or -gno-small-inline-functions with a hardcoded threshold to implement the feature Paul described, and this patch seems to be a step in that direction, with the threshold being hardcoded to 0.

OK. :)

We are motivated by one tool in particular at the moment, but if we're going to take the time to add a knob, we might as well make it work for DWARF.

Here you got me confused: When I read "we might as well make it work for DWARF", I read that as "we should emit the inlined instructions with line 0 under a DWARF debugger tuning". But that reading seems to to contradict your next sentence:

If the user cares enough to find this flag, it seems more user friendly to make it behave the same rather than making it format-dependent.

Can you clarify?

If we use line zero for DWARF, gdb will not behave in the way documented by the function attribute in LangRef. I was the one who suggested the wording there, so maybe we could come up with new wording that describes what the user should expect in the debugger when using line zero. However, given the behavior I show below, I have a hard time imagining the use case for it.

I applied the version of this patch that uses getMergedLocation, compiled this program, and ran it under gdb:

volatile int x;
static inline void foo() {
  ++x;
  *(volatile int*)0 = 42; // crash
  ++x;
}
int main() {
  ++x;  // line 8
  foo();  // line 9
  ++x;
  return x;
}

If we apply line zero, the debugger stops on line 8:

Program received signal SIGSEGV, Segmentation fault.
0x000000000040111e in main () at t.cpp:8
8         ++x;
(gdb) bt
#0  0x000000000040111e in main () at t.cpp:8

The inline frame is gone, as expected for this flag, but the current location does not reflect the site of the call to foo. So, if we want it to behave as documented, we have to put the call site location on some instructions.

Alternatively, if I arrange things like this, the crash is attributed to line return x, which is completely unrelated to the inline call site:

static inline void foo() {
  ++x;
  if (x) {
    *(volatile int*)0 = 42; // crash
    __builtin_unreachable();
  }
  ++x;
}

This means that if line zero is used, the source location shown in the debugger becomes sensitive to code layout, which is arbitrary.

These experiments are convincing me that, in general, line zero isn't that helpful for DWARF consumers. If the goal is to get smooth stepping, we may want to refocus on getting reliable is_stmt bits in the line table.

[probinson]

These experiments are convincing me that, in general, line zero isn't that helpful for DWARF consumers. If the goal is to get smooth stepping, we may want to refocus on getting reliable is_stmt bits in the line table.

If you mean, it's not useful for identifying the call site as the implicit source for the inlined function, well, yeah. Line 0 means "there is no useful source location to attach to this instruction" and it's not what you want here. Based solely on the description of /Zo- in the Microsoft docs, I'd guess it behaves more like Sony's original implementation: Instead of attaching the call-site location using InlinedAt, just replace the original source location with the call-site location.

Adrian's point that line 0 would be less misleading for profilers etc is true, but as a couple of Dev Meeting discussions suggested, there is no one solution that will please all consumers (unless we invent a more complicated line table that provides everyone with the answers they want). My thinking is that if the user *asked* to suppress inlined scopes, then profiling is not their major concern, and there's no benefit to using line 0 here.

[aprantl]

In D67723#1720353, @rnk wrote:

In D67723#1717468, @aprantl wrote:

I agree that it would make sense to have a -ginline-info-threshold=<#insns> or -gno-small-inline-functions with a hardcoded threshold to implement the feature Paul described, and this patch seems to be a step in that direction, with the threshold being hardcoded to 0.

OK. :)

We are motivated by one tool in particular at the moment, but if we're going to take the time to add a knob, we might as well make it work for DWARF.

Here you got me confused: When I read "we might as well make it work for DWARF", I read that as "we should emit the inlined instructions with line 0 under a DWARF debugger tuning". But that reading seems to to contradict your next sentence:

If the user cares enough to find this flag, it seems more user friendly to make it behave the same rather than making it format-dependent.

Can you clarify?

If we use line zero for DWARF, gdb will not behave in the way documented by the function attribute in LangRef. I was the one who suggested the wording there, so maybe we could come up with new wording that describes what the user should expect in the debugger when using line zero. However, given the behavior I show below, I have a hard time imagining the use case for it.

I didn't realize that GDB also had problems; I thought that this was a problem that only affected Windows debuggers.

I applied the version of this patch that uses getMergedLocation, compiled this program, and ran it under gdb:

volatile int x;
static inline void foo() {
  ++x;
  *(volatile int*)0 = 42; // crash
  ++x;
}
int main() {
  ++x;  // line 8
  foo();  // line 9
  ++x;
  return x;
}

If we apply line zero, the debugger stops on line 8:

Program received signal SIGSEGV, Segmentation fault.
0x000000000040111e in main () at t.cpp:8
8         ++x;
(gdb) bt
#0  0x000000000040111e in main () at t.cpp:8

The inline frame is gone, as expected for this flag, but the current location does not reflect the site of the call to foo. So, if we want it to behave as documented, we have to put the call site location on some instructions.

Alternatively, if I arrange things like this, the crash is attributed to line return x, which is completely unrelated to the inline call site:

static inline void foo() {
  ++x;
  if (x) {
    *(volatile int*)0 = 42; // crash
    __builtin_unreachable();
  }
  ++x;
}

This means that if line zero is used, the source location shown in the debugger becomes sensitive to code layout, which is arbitrary.

These experiments are convincing me that, in general, line zero isn't that helpful for DWARF consumers. If the goal is to get smooth stepping, we may want to refocus on getting reliable is_stmt bits in the line table.

The Swift compiler is far more aggressive in using line 0 than Clang, and consequently LLDB is much better at handling line 0 than even GDB, and that can skew my perception :-)

Give how popular GDB is, I don't want to intentionally break compatibility with it, so I think this patch is okay. If we wanted we can put an if-debugger-tuning-is-LLDB-getMergedLocation condition in. Otherwise documenting that this is necessary for compatibility with popular debuggers, seems fine to me, too.

[aprantl]

tldr: my LGTM still stands.

[dblaikie]

In D67723#1720509, @aprantl wrote:

In D67723#1720353, @rnk wrote:

In D67723#1717468, @aprantl wrote:

I agree that it would make sense to have a -ginline-info-threshold=<#insns> or -gno-small-inline-functions with a hardcoded threshold to implement the feature Paul described, and this patch seems to be a step in that direction, with the threshold being hardcoded to 0.

OK. :)

We are motivated by one tool in particular at the moment, but if we're going to take the time to add a knob, we might as well make it work for DWARF.

Here you got me confused: When I read "we might as well make it work for DWARF", I read that as "we should emit the inlined instructions with line 0 under a DWARF debugger tuning". But that reading seems to to contradict your next sentence:

If the user cares enough to find this flag, it seems more user friendly to make it behave the same rather than making it format-dependent.

Can you clarify?

If we use line zero for DWARF, gdb will not behave in the way documented by the function attribute in LangRef. I was the one who suggested the wording there, so maybe we could come up with new wording that describes what the user should expect in the debugger when using line zero. However, given the behavior I show below, I have a hard time imagining the use case for it.

I didn't realize that GDB also had problems; I thought that this was a problem that only affected Windows debuggers.

I don't think the behavior Reid described would be a "problem" - it seems to me like the only behavior the debugger could provide if those instructions are attributed to line zero.

I applied the version of this patch that uses getMergedLocation, compiled this program, and ran it under gdb:

volatile int x;
static inline void foo() {
  ++x;
  *(volatile int*)0 = 42; // crash
  ++x;
}
int main() {
  ++x;  // line 8
  foo();  // line 9
  ++x;
  return x;
}

If we apply line zero, the debugger stops on line 8:

Program received signal SIGSEGV, Segmentation fault.
0x000000000040111e in main () at t.cpp:8
8         ++x;
(gdb) bt
#0  0x000000000040111e in main () at t.cpp:8

The inline frame is gone, as expected for this flag, but the current location does not reflect the site of the call to foo. So, if we want it to behave as documented, we have to put the call site location on some instructions.

Alternatively, if I arrange things like this, the crash is attributed to line return x, which is completely unrelated to the inline call site:

static inline void foo() {
  ++x;
  if (x) {
    *(volatile int*)0 = 42; // crash
    __builtin_unreachable();
  }
  ++x;
}

This means that if line zero is used, the source location shown in the debugger becomes sensitive to code layout, which is arbitrary.

These experiments are convincing me that, in general, line zero isn't that helpful for DWARF consumers. If the goal is to get smooth stepping, we may want to refocus on getting reliable is_stmt bits in the line table.

The Swift compiler is far more aggressive in using line 0 than Clang, and consequently LLDB is much better at handling line 0 than even GDB, and that can skew my perception :-)

What behavior does LLDB have in the example Reid gave?

Give how popular GDB is, I don't want to intentionally break compatibility with it, so I think this patch is okay. If we wanted we can put an if-debugger-tuning-is-LLDB-getMergedLocation condition in. Otherwise documenting that this is necessary for compatibility with popular debuggers, seems fine to me, too.

[akhuang]

Seems like this is good to be committed then. And it sounds like implementing more thresholds would be useful to do in the future.

clang/include/clang/Basic/CodeGenOptions.def

 CODEGENOPT(NoCommon          , 1, 0) ///< Set when -fno-common or C++ is enabled.
 CODEGENOPT(NoDwarfDirectoryAsm , 1, 0) ///< Set when -fno-dwarf-directory-asm is
                                        ///< enabled.
 CODEGENOPT(NoExecStack       , 1, 0) ///< Set when -Wa,--noexecstack is enabled.
 CODEGENOPT(FatalWarnings     , 1, 0) ///< Set when -Wa,--fatal-warnings is
                                      ///< enabled.
 CODEGENOPT(NoWarn            , 1, 0) ///< Set when -Wa,--no-warn is enabled.
 CODEGENOPT(EnableSegmentedStacks , 1, 0) ///< Set when -fsplit-stack is enabled.
+CODEGENOPT(NoInlineLineTables, 1, 0) ///< Whether debug info should contain
+                                     ///< inline line tables.
 CODEGENOPT(NoImplicitFloat   , 1, 0) ///< Set when -mno-implicit-float is enabled.
 CODEGENOPT(NoInfsFPMath      , 1, 0) ///< Assume FP arguments, results not +-Inf.
 CODEGENOPT(NoSignedZeros     , 1, 0) ///< Allow ignoring the signedness of FP zero
 CODEGENOPT(NullPointerIsValid , 1, 0) ///< Assume Null pointer deference is defined.
 CODEGENOPT(Reassociate       , 1, 0) ///< Allow reassociation of FP math ops
 CODEGENOPT(ReciprocalMath    , 1, 0) ///< Allow FP divisions to be reassociated.
 CODEGENOPT(NoTrappingMath    , 1, 0) ///< Set when -fno-trapping-math is enabled.
 CODEGENOPT(NoNaNsFPMath      , 1, 0) ///< Assume FP arguments, results not NaN.

clang/include/clang/Driver/Options.td

 
 def gcodeview : Flag<["-"], "gcodeview">,
   HelpText<"Generate CodeView debug information">,
   Flags<[CC1Option, CC1AsOption, CoreOption]>;
 def gcodeview_ghash : Flag<["-"], "gcodeview-ghash">,
   HelpText<"Emit type record hashes in a .debug$H section">,
   Flags<[CC1Option, CoreOption]>;
 def gno_codeview_ghash : Flag<["-"], "gno-codeview-ghash">, Flags<[CoreOption]>;
+def ginline_line_tables : Flag<["-"], "ginline-line-tables">, Flags<[CoreOption]>;
+def gno_inline_line_tables : Flag<["-"], "gno-inline-line-tables">,
+  Flags<[CC1Option, CoreOption]>, HelpText<"Don't emit inline line tables">;
 
 // Equivalent to our default dwarf version. Forces usual dwarf emission when
 // CodeView is enabled.
 def gdwarf : Flag<["-"], "gdwarf">, Alias<gdwarf_4>, Flags<[CoreOption]>;
 
 def gfull : Flag<["-"], "gfull">, Group<g_Group>;
 def gused : Flag<["-"], "gused">, Group<g_Group>;
 def gstabs : Joined<["-"], "gstabs">, Group<g_Group>, Flags<[Unsupported]>;

clang/lib/CodeGen/CodeGenFunction.cpp

if (const auto *XRayAttr = D->getAttr<XRayInstrumentAttr>()) {
             llvm::itostr(CGM.getCodeGenOpts().XRayInstructionThreshold));
     }
   }
 
   // Add no-jump-tables value.
   Fn->addFnAttr("no-jump-tables",
                 llvm::toStringRef(CGM.getCodeGenOpts().NoUseJumpTables));
 
+  // Add no-inline-line-tables value.
+  if (CGM.getCodeGenOpts().NoInlineLineTables)
+    Fn->addFnAttr("no-inline-line-tables");
+
   // Add profile-sample-accurate value.
   if (CGM.getCodeGenOpts().ProfileSampleAccurate)
     Fn->addFnAttr("profile-sample-accurate");
 
   if (D && D->hasAttr<CFICanonicalJumpTableAttr>())
     Fn->addFnAttr("cfi-canonical-jump-table");
 
   if (getLangOpts().OpenCL) {

clang/lib/Driver/ToolChains/Clang.cpp

if (EmitCodeView) {
 
     // Emit codeview type hashes if requested.
     if (Args.hasFlag(options::OPT_gcodeview_ghash,
                      options::OPT_gno_codeview_ghash, false)) {
       CmdArgs.push_back("-gcodeview-ghash");
     }
   }
 
+  // Omit inline line tables if requested.
+  if (!Args.hasFlag(options::OPT_ginline_line_tables,
+                    options::OPT_gno_inline_line_tables, false)) {
+    CmdArgs.push_back("-gno-inline-line-tables");
+  }
+
   // Adjust the debug info kind for the given toolchain.
   TC.adjustDebugInfoKind(DebugInfoKind, Args);
 
   RenderDebugEnablingArgs(Args, CmdArgs, DebugInfoKind, DWARFVersion,
                           DebuggerTuning);
 
   // -fdebug-macro turns on macro debug info generation.
   if (Args.hasFlag(options::OPT_fdebug_macro, options::OPT_fno_debug_macro,

clang/lib/Frontend/CompilerInvocation.cpp

Opts.NewStructPathTBAA = !Args.hasArg(OPT_no_struct_path_tbaa) &&
                            Args.hasArg(OPT_new_struct_path_tbaa);
   Opts.FineGrainedBitfieldAccesses =
       Args.hasFlag(OPT_ffine_grained_bitfield_accesses,
                    OPT_fno_fine_grained_bitfield_accesses, false);
   Opts.DwarfDebugFlags = Args.getLastArgValue(OPT_dwarf_debug_flags);
   Opts.RecordCommandLine = Args.getLastArgValue(OPT_record_command_line);
   Opts.MergeAllConstants = Args.hasArg(OPT_fmerge_all_constants);
   Opts.NoCommon = Args.hasArg(OPT_fno_common);
+  Opts.NoInlineLineTables = Args.hasArg(OPT_gno_inline_line_tables);
   Opts.NoImplicitFloat = Args.hasArg(OPT_no_implicit_float);
   Opts.OptimizeSize = getOptimizationLevelSize(Args);
   Opts.SimplifyLibCalls = !(Args.hasArg(OPT_fno_builtin) ||
                             Args.hasArg(OPT_ffreestanding));
   if (Opts.SimplifyLibCalls)
     getAllNoBuiltinFuncValues(Args, Opts.NoBuiltinFuncs);
   Opts.UnrollLoops =
       Args.hasFlag(OPT_funroll_loops, OPT_fno_unroll_loops,

clang/test/CodeGen/debug-info-no-inline-line-tables.c

+// RUN: %clang_cc1 -triple x86_64-windows-msvc -gcodeview -debug-info-kind=limited \
+// RUN:   -gno-inline-line-tables -emit-llvm -o - %s | FileCheck %s
+
+int x;
+__attribute((always_inline)) void f() {
+  x += 1;
+}
+int main() {
+  f();
+  x += 2;
+  return x;
+}
+
+// Check that clang emits the location with line 0 and not the location of the
+// inlined function in the debug info.
+// CHECK: define dso_local i32 @main()
+// CHECK: %{{.+}} = load i32, i32* @x, align 4, !dbg [[DbgLoc:![0-9]+]]
+
+// Check that the no-inline-line-tables attribute is added.
+// CHECK: attributes #0 = {{.*}}"no-inline-line-tables"{{.*}}
+// CHECK: attributes #1 = {{.*}}"no-inline-line-tables"{{.*}}
+
+// CHECK: [[DbgLoc]] = !DILocation(line: 0,
+// CHECK-NOT:  inlinedAt:

llvm/docs/LangRef.rst

 ``minsize``
     This attribute suggests that optimization passes and code generator
     passes make choices that keep the code size of this function as small
     as possible and perform optimizations that may sacrifice runtime
     performance in order to minimize the size of the generated code.
 ``naked``
     This attribute disables prologue / epilogue emission for the
     function. This can have very system-specific consequences.
+``"no-inline-line-tables"``
+    When this attribute is set to true, the inliner discards source locations
+    when inlining code and instead uses the source location of the call site.
+    Breakpoints set on code that was inlined into the current function will
+    not fire during the execution of the inlined call sites. If the debugger
+    stops inside an inlined call site, it will appear to be stopped at the
+    outermost inlined call site.
 ``no-jump-tables``
     When this attribute is set to true, the jump tables and lookup tables that
     can be generated from a switch case lowering are disabled.
 ``nobuiltin``
     This indicates that the callee function at a call site is not recognized as
     a built-in function. LLVM will retain the original call and not replace it
     with equivalent code based on the semantics of the built-in function, unless
     the call site uses the ``builtin`` attribute. This is valid at call sites

llvm/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 NoInlineLineTables : StrBoolAttr<"no-inline-line-tables">;
 def ProfileSampleAccurate : StrBoolAttr<"profile-sample-accurate">;
 
 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

llvm/lib/Transforms/Utils/InlineFunction.cpp

InlinedAtNode = DILocation::getDistinct(
       Ctx, InlinedAtNode->getLine(), InlinedAtNode->getColumn(),
       InlinedAtNode->getScope(), InlinedAtNode->getInlinedAt());
 
   // Cache the inlined-at nodes as they're built so they are reused, without
   // this every instruction's inlined-at chain would become distinct from each
   // other.
   DenseMap<const MDNode *, MDNode *> IANodes;
 
+  // Check if we are not generating inline line tables and want to use
+  // the call site location instead.
+  bool NoInlineLineTables = Fn->hasFnAttribute("no-inline-line-tables");
+
   for (; FI != Fn->end(); ++FI) {
     for (BasicBlock::iterator BI = FI->begin(), BE = FI->end();
          BI != BE; ++BI) {
       // Loop metadata needs to be updated so that the start and end locs
       // reference inlined-at locations.
       if (MDNode *LoopID = BI->getMetadata(LLVMContext::MD_loop)) {
         MDNode *NewLoopID =
             inlineLoopID(LoopID, InlinedAtNode, BI->getContext(), IANodes);
         BI->setMetadata(LLVMContext::MD_loop, NewLoopID);
       }
 
+      // If we are not generating inline line tables, set the debug location
+      // of the inlined code to be the call location.
+      if (NoInlineLineTables) {
+        // Remove debug info intrinsics.
+        if (auto *DbgInst = dyn_cast<DbgVariableIntrinsic>(BI)) {
+          BI = --(DbgInst->eraseFromParent());
+          continue;
+        }
+        BI->setDebugLoc(
+            DILocation::getMergedLocation(TheCallDL, BI->getDebugLoc()));
+        continue;
+      }
+
       if (DebugLoc DL = BI->getDebugLoc()) {
         DebugLoc IDL =
             inlineDebugLoc(DL, InlinedAtNode, BI->getContext(), IANodes);
         BI->setDebugLoc(IDL);
         continue;
       }
 
       if (CalleeHasDebugInfo)
         continue;
 
       // If the inlined instruction has no line number, make it look as if it
       // originates from the call location. This is important for
       // ((__always_inline__, __nodebug__)) functions which must use caller
       // location for all instructions in their function body.
 
       // Don't update static allocas, as they may get moved later.
       if (auto *AI = dyn_cast<AllocaInst>(BI))
         if (allocaWouldBeStaticInEntry(AI))
           continue;
 
       BI->setDebugLoc(TheCallDL);
     }
   }
 }
 
 /// Update the block frequencies of the caller after a callee has been inlined.
 ///
 /// Each block cloned into the caller has its block frequency scaled by the
 /// ratio of CallSiteFreq/CalleeEntryFreq. This ensures that the cloned copy of

llvm/test/Transforms/Inline/no-inline-line-tables.ll

+; RUN: opt < %s -inline -S | FileCheck %s
+
+; This tests that functions with the attribute `no-inline-line-tables` have the
+; correct debug information when they are inlined.
+
+; ModuleID = 't.c'
+source_filename = "t.c"
+target datalayout = "e-m:w-p270:32:32-p271:32:32-p272:64:64-i64:64-f80:128-n8:16:32:64-S128"
+target triple = "x86_64-unknown-windows-msvc"
+
+; Function Attrs: alwaysinline nounwind
+define dso_local i32 @f(i32 %i) #0 !dbg !7 {
+entry:
+  %i.addr = alloca i32, align 4
+  store i32 %i, i32* %i.addr, align 4
+  call void @llvm.dbg.declare(metadata i32* %i.addr, metadata !12, metadata !DIExpression()), !dbg !13
+  %0 = load i32, i32* %i.addr, align 4, !dbg !14
+  ret i32 %0, !dbg !14
+}
+
+; Function Attrs: nounwind readnone speculatable willreturn
+declare void @llvm.dbg.declare(metadata, metadata, metadata) #1
+
+; Check that debug info for inlined code uses line 0 and that debug intrinsics
+; are removed.
+; Function Attrs: noinline nounwind optnone
+define dso_local i32 @main() #2 !dbg !15 {
+entry:
+; CHECK-LABEL: @main()
+; CHECK-NOT: @f
+; CHECK-NOT: @llvm.dbg.declare
+; CHECK: %{{[0-9]+}} = load i32, i32* %i.addr.i, align 4, !dbg ![[VAR:[0-9]+]]
+; CHECK: ![[VAR]] = !DILocation(line: 0, scope: !{{[0-9]+}})
+  %call = call i32 @f(i32 23), !dbg !18
+  ret i32 0, !dbg !19
+}
+
+attributes #0 = { alwaysinline nounwind "no-inline-line-tables" }
+attributes #2 = { noinline nounwind optnone "no-inline-line-tables"}
+
+!llvm.dbg.cu = !{!0}
+!llvm.module.flags = !{!3, !4, !5}
+!llvm.ident = !{!6}
+
+!0 = distinct !DICompileUnit(language: DW_LANG_C99, file: !1, producer: "clang version 10.0.0 (https://github.com/llvm/llvm-project.git cb37bd6bbb4ca4b23838b08412d976bdab07e4fe)", isOptimized: false, runtimeVersion: 0, emissionKind: FullDebug, enums: !2, nameTableKind: None)
+!1 = !DIFile(filename: "<stdin>", directory: "/usr/local/google/home/akhuang/testing/inline-line-tables", checksumkind: CSK_MD5, checksum: "69f4cc67a00fe0c3f251a593209753fd")
+!2 = !{}
+!3 = !{i32 2, !"CodeView", i32 1}
+!4 = !{i32 2, !"Debug Info Version", i32 3}
+!5 = !{i32 1, !"wchar_size", i32 2}
+!6 = !{!"clang version 10.0.0 (https://github.com/llvm/llvm-project.git cb37bd6bbb4ca4b23838b08412d976bdab07e4fe)"}
+!7 = distinct !DISubprogram(name: "f", scope: !8, file: !8, line: 1, type: !9, scopeLine: 1, flags: DIFlagPrototyped, spFlags: DISPFlagDefinition, unit: !0, retainedNodes: !2)
+!8 = !DIFile(filename: "t.c", directory: "/usr/local/google/home/akhuang/testing/inline-line-tables", checksumkind: CSK_MD5, checksum: "69f4cc67a00fe0c3f251a593209753fd")
+!9 = !DISubroutineType(types: !10)
+!10 = !{!11, !11}
+!11 = !DIBasicType(name: "int", size: 32, encoding: DW_ATE_signed)
+!12 = !DILocalVariable(name: "i", arg: 1, scope: !7, file: !8, line: 1, type: !11)
+!13 = !DILocation(line: 1, scope: !7)
+!14 = !DILocation(line: 2, scope: !7)
+!15 = distinct !DISubprogram(name: "main", scope: !8, file: !8, line: 4, type: !16, scopeLine: 4, spFlags: DISPFlagDefinition, unit: !0, retainedNodes: !2)
+!16 = !DISubroutineType(types: !17)
+!17 = !{!11}
+!18 = !DILocation(line: 5, scope: !15)
+!19 = !DILocation(line: 6, scope: !15)