Proposal for multi location debug info support in LLVM IR

Project Infrastructure LLVM Dev List Archives
1

I will be out of the office on January 7th and will return on January 19th. I will not have access to email during this time. Please contact Karen Lavelle at klavelle@rice.edu or 713-348-2062 if you have any questions or concerns.

Best regards,
Annepha

2

I’m reading/following along - discussion so far sounds reasonable to me.

Only minor note: if dbg.value/declare can be narrowed down to one (I think you mentioned in your original proposal that it seemed like everything could be just dbg.value?) that’d be a good step, regardless - possibly ahead of/while this conversation is underway. Or is it the case that the proposed enhanced semantics are required before that transition (because currently dbg.value only goes to the end of the BB? if I recall correctly, whereas dbg.declare is the whole function)? In the latter case, perhaps it’d be a good first step/goal/transition to do as cleanup/generalization anyway.

  • Dave
3

Adrian had proposed the following staging:

  1. Remove offset argument from dbg.value
  2. Unify dbg.value and dbg.declare
  3. Full implementation

I’m not yet sure what to do about the difference in dbg.declare semantics. For example, i think the following currently works

top:
%x = alloca
br else

if:
dbg.declare(%x...
unreachable

else:
# dbg.declare still applies here

I think it would be reasonable to switch to the proposed dominance semantics during step 2, but we’ll have to see if that negatively affects any real-world test cases.

4

Adrian had proposed the following staging:

1. Remove offset argument from dbg.value
2. Unify dbg.value and dbg.declare
3. Full implementation

I'm not yet sure what to do about the difference in dbg.declare semantics.
For example, i think the following currently works

```
top:
%x = alloca
br else

if:
dbg.declare(%x...
unreachable

else:
# dbg.declare still applies here

Hmm - I thought we had some (perhaps undocumented) rule that dbg.declares
should all go in the entry with the allocas? I assume Clang follows this
rule at least.

5

We do, ish, but it’s not enforced as far as I can tell. I do think there is a situation where clang can create such code (don’t ask me how though, I encountered it while hunting a different bug and just noticed it looked odd). This was during an LTO build, so inlining related perhaps?

6

We do, ish, but it's not enforced as far as I can tell. I do think there
is a situation where clang can create such code (don't ask me how though, I
encountered it while hunting a different bug and just noticed it looked
odd). This was during an LTO build, so inlining related perhaps?

Possible... but I don't know