[PATCH] D67500: [DebugInfo] LiveDebugValues: don't create transfer records for potentially invalid locations

[Adrian Prantl via Phabricator via llvm-commits]

aprantl added a comment.

In D67500#1861979 <https://reviews.llvm.org/D67500#1861979>, @jmorse wrote:

> Adrian wrote:
>
> > My understanding is that for each DBG_VALUE d in the analyzed MIR function and each instruction i
> > 
> > - true means: "it is correct to insert d at position i"
> > - false means: "it would be wrong to insert d at position i"
> > 
> > In other words at each instruction i the set of DBG_VALUEs that are "true" are the set of "live" DBG_VALUEs.
>
> I agree,
>
> [...]
>
> > I *think* I just described something isomorphic to your type (2), just using other names.
>
> Yup, sounds like we're in violent agreement then.
>
> There are now only (!) two big differences between this model and what the LiveDebugValues code actually does. I think they're sound, and will explain below. If it sounds sound, I can bake this into file documentation for everyones future reference.


That would be great, and if any of our functions can benefit from renaming to fit established nomenclature, we should do that, too.

> 1, The implicit "Unknown" value: We don't actually represent your \bot at all, instead a location in a block is implicitly unknown until the block is explored.

It's not represented in the *data* at all since we only have a set, it just falls out of the algorithm. Can you remind me why this works again? Is it because we visit each block locally once before calling any join() function?

> Practically, this means that the result of a join(...) can only ever be your true or \top. Given that we always explore in reverse-post-order, there's always an explored path back to the entry block where the value must begin \top. That means there's always a predecessor that has a value \top or true: so we can never produce a \bot from join anyway.
> 
> 2, We don't "know" in advance about locations that are discovered during location propagation. For example, when we have in a block, after some control flow:
> 
>   DBG_VALUE $rax, ...
>   $rbx = COPY $rax 
>    
> 
> And no other variable location was in $rbx, then during exploration we create a new variable location of "$rbx" without exploring its behaviour from the entry block. Implicitly, all predecessor blocks get initialized to \top value for that variable location. I think this is /OK/ but messy. Given that the variable location was not seen when exploring predecessor blocks, they would have had \top propagated into them anyway from the entry block.

How is this different from discovering a DBG_VALUE the first time?

> Successor blocks could potentially be initialized to \top too if the new location is discovered after the first dataflow iteration, and that could artifically limit the range of the variable location. However, I think in practice that these locations are _always_ found on the first iteration: we only ever move "up" your lattice and have no unknown values after a block is explored; therefore the maximum number of locations will be "true" on the first iteration; and so any new location that could be found _must_ be found on the first iteration.




Repository:
  rL LLVM

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

https://reviews.llvm.org/D67500