[clang] [clang][DebugInfo] Add inlined subprogram metadata for compiler built-ins (PR #189969)

[J. Ryan Stinnett via cfe-commits]

jryans wrote:

> Could there any concern over the maintenance of how to categorise new/changed builtins? Could this lead to inconsistent behaviour, if it's easy to forget to update this in the future - is there a way to ensure that's caught by tests?

I understand the concern, but at least in my view, the risk is low. If a new built-in is added that (let's say) happens to directly emit a call (and is not marked as library function, as we already handle that category automatically), then the work here would wrap the call in additional inlined layer. Nothing truly incorrect has happened, but there would be a somewhat redundant layer of inlined subroutine wrapping present.

The largest categories that need excluding are library function built-ins and target-specific built-ins. The exceptions for these two categories are applied automatically, so there is no list to worry about for future additions of these.

That leaves the "miscellaneous" built-ins implemented in various parts of the huge `switch` statement in `CGBuiltin.cpp`. For nearly all of these, the default-enabled state of this inlined treatment seems reasonable, as they are calls to functions that affect runtime program state.

I would expect the growth of the categories that are listed in the manual exceptions list to be quite rare.

I did consider some means of automatically detecting e.g. whether the built-in emits only a call as part of the switch statement, but that felt perhaps more trouble than it was worth. Even with such a thing, there would still be some cases we'd want to exclude, so it wouldn't fully remove the exceptions list.

As for testing, the PR includes a few tests of this behaviour for existing built-ins. I am not quite sure how to construct a test for potential future built-ins, since we don't know in advance whether the treatment applies or not. Again though, forgetting to add an exception where it might be warranted is a low-risk thing that adds a small amount of redundant debug info wrapping.

https://github.com/llvm/llvm-project/pull/189969