[llvm] [DebugInfo] getMergedLocation: match scopes based on their location (PR #132286)

[Vladislav Dzhidzhoev via llvm-commits]

dzhidzhoev wrote:

> the textual description of this issue I'm finding a bit hard to follow - could you sketch out a little example, perhaps - some approximation of the source situation, the two location chains in question, the location chain that's produced currently when they're merged, and the location chain that'll be produced after this patch?

Sorry, I should probably rewrite that (but not sure about the wording yet).

The issue https://github.com/llvm/llvm-project/issues/122846 arose while using an external non-C++ language frontend, which has a feature of inlining on the frontend side, that produces semantically identical subtrees of DILocalScopes at call sites of a function being inlined. In some cases, a call site and a callee function are from different source files.

On the current mainline, MergeLocPair() within getMergedLocation() doesn't consider the case of DILocation's or their nearest common scope being from different files at all. It can be solved just by ensuring the equality of input DILocations' files and output DILocation's file after the GetNearestCommonScope() call.

However, with that approach, many source locations will be lost with the frontend I mentioned before. What this patch is trying to achieve is that if there are two DILocalScope subtrees that de facto represent the same source code (probably included into different files/parent scopes), and DILocations being merged belong to these subtrees, GetNearestCommonScope should be able to return a scope that it would return if both input DILocations belonged to a single DILocalScope subtree (not to different subtrees representing the same source). This is implemented by having GetNearestCommonScope consider DILocalScope's equal not based on pointer equality, but on the equality of their locations (line number, column number, and file).

There's an example in merge-nested-block-loc2.ll. We may consider two files, the locations from which will be merged:

z1.c:
```c
  # 100 "z1.c" 1
  i += a;
  i -= 10*a;
  i *= a*a;

```
z2.c:
```c
  # 200 "z2.c" 1
  i += a;
  i -= 10*a;
  i *= a*a;

```

They are both included from another file.

y.c:
```c
  # 300 "y.c" 1
  do {
  #ifdef A
  #include "z1.c"
  #else
  #include "z2.c"
  #endif
  } while (0);
```

Which is included from the "root" file two times. There, include directives "simulate" the inlining of a single function (y.c) at two different locations, with different arguments (preprocessor symbol A as an "argument").

main.c:
```c
int foo(int a) {
  int i = 0;
  if ((a & 1) == 1) {
    a -= 1;
#define A
#include "y.c"
 } else {
    a += 3;
#undef A
#include "y.c"
 }
  return i;
}
```

DILocalScopes tree produced from this source code will be similar to that:

```
DILocalScopes of y.c included from if-branch of foo() ==> DILocalScopes of z1.c
    ^
    |
DILocalScopes for foo() from main.c
    |
    v
DILocalScopes of y.c included from else-branch of foo() ==> DILocalScopes of z2.c
```

On the current mainline, merging two locations from z1.c and z2.c will result in a location having a scope from main.c.
With this patch, the output location will have a scope from y.c.


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