[llvm] [DebugInfo] Merge partially matching chains of textual inclusions (PR #125780)

[Vladislav Dzhidzhoev via llvm-commits]

dzhidzhoev wrote:

> Thanks for the patch! I'm not too familiar with debug info for textual-inclusions or DILexicalBlockFile, but from what I can tell, a much simpler approach may be possible here. The reason why we merge partially-matching chains of inlined functions is that we create a series of inline stack frames from that chain - so it is possible for example to have 3 stack frames at the same instruction, where the top and bottom frames have a valid line number while the middle frame has line 0.

Thank you for the explanation. As far as I understood, by using the partial-matching algorithm, we're trying to find the "nearest" subprogram to the incoming locations such that we can produce the nearest subprogram for all "upper" subprograms in chain/stack.



> In the case of textual inclusion, we don't produce any inline stack frames - the frame is always just the current subroutine, albeit with a different file. Because of this, partial matching chains of textual inclusion wouldn't give an output that would be visible in a debugger - the only thing that would matter is whether the top "frames" match. I think it makes sense to treat the file more like the outermost part of the line+column matching, i.e. if the files don't match then we use a line 0 in the nearest common scope, and if the files do match then we use that matching file (creating a new DILexicalBlockFile at the nearest common scope if necessary).

I've tried that approach. The problem is that, if we consider the example below, the nearest common scope for phi instruction for the variable "i" before return statement is DISubprogram, whereas what this patch tries to achieve is that we would use "the closest" common file to the incoming location.


main.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;
}
```

y.c

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

z1.c

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

z2.c

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

Here, we can't get the location "y.c:300" assigned to the variable because we have two different DILexicalBlock objects, though produced by the inclusion of the same file.  So, it seems that we have to walk top-down over the sequence of included lexical blocks to find the least semantically matching lexical block.

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