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

[Jeremy Morse via Phabricator via llvm-commits]

jmorse added a comment.

> 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?

I think it's because at least one predecessor is guaranteed to have been visited first (except for the entry block), which ensures there is at least one non-unknown lattice value join(...) to return. Inductively,

- The entry block always starts with \top,
- join(...) can only return Unknown (\bot) if all inputs are Unknown

And because we only visit a block when its predecessors have been visited, join() will never see a block where all its predecessors have Unknown values.

This might fall apart if the entry block is also a loop head, but I think the entry block always starting with \top might fix that.

>> [Locations being discovered during exploration]
> 
> How is this different from discovering a DBG_VALUE the first time?

I guess it isn't different really. For *any* variable location we might only start tracking it when it's discovered during exploration, instead of tracking it from the entry block. To reform the question: do we still correctly implement the dataflow analysis if we begin tracking variable locations after exploration starts, instead of tracking from the entry block? As explained above, I think we get correct values for previously explored blocks (i.e., \top), and I think we're not artificially limiting "new" locations to \top in later blocks because they should all be found on the first iteration.


Repository:
  rL LLVM

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

https://reviews.llvm.org/D67500