[PATCH] D67723: [DebugInfo] Add option to disable inline line tables.

[Paul Robinson via Phabricator via cfe-commits]

probinson added a comment.

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.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D67723/new/

https://reviews.llvm.org/D67723