[PATCH] D136335: [Assignment Tracking Analysis][5/*] Tests
Jeremy Morse via Phabricator via llvm-commits
llvm-commits at lists.llvm.org
Fri Nov 25 04:33:20 PST 2022
jmorse added a comment.
Just thinking out loud about coverage -- it seems to me that there are several dimensions over which the assignment-tracking lattice analysis should run, which are:
- The domain of dbg.assign "state"/value, i.e. whether it has complete information in the intrinsic: {``both`, `value-only`, `link-only`, `neither`},
- Whether there's a linked store or not,
- Whether the store comes before or after the intrinsic,
- CFG patterns between the store, intrinsic, and intrinsics with a different state/value, i.e. whether there's straight-line-code, diamonds, loops, in the way.
Put it all together and you get something like 50 or 60 different scenarios to test. We don't need explicit tests for every single path through the compiler, however to my mind what we're missing right now is interactions between loops and dbg.assigns with different states. This is something that LiveDebugValues used to get very wrong. For example, IMO we want an explicit test like loop-sink.ll but where there's a second loop exit path where there's a dbg.value(undef,). In that situation we'd want to ensure that the subsequent store doesn't become the variable location.
CHANGES SINCE LAST ACTION
https://reviews.llvm.org/D136335/new/
https://reviews.llvm.org/D136335
More information about the llvm-commits
mailing list