Djordje Todorovic 4cfceb9106 [LiveDebugValues] Introduce entry values of unmodified params ... The idea is to remove front-end analysis for the parameter's value modification and leave it to the value tracking system. Front-end in some cases marks a parameter as modified even the line of code that modifies the parameter gets optimized, that implies that this will cover more entry values even. In addition, extending the support for modified parameters will be easier with this approach. Since the goal is to recognize if a parameter’s value has changed, the idea at very high level is: If we encounter a DBG_VALUE other than the entry value one describing the same variable (parameter), we can assume that the variable’s value has changed and we should not track its entry value any more. That would be ideal scenario, but due to various LLVM optimizations, a variable’s value could be just moved around from one register to another (and there will be additional DBG_VALUEs describing the same variable), so we have to recognize such situation (otherwise, we will lose a lot of entry values) and salvage the debug entry value. Differential Revision: https://reviews.llvm.org/D68209		2019-12-03 11:01:45 +01:00
..
support	[lldbsuite] Remove unused support files	2019-10-29 16:56:59 -07:00
test	[LiveDebugValues] Introduce entry values of unmodified params	2019-12-03 11:01:45 +01:00
test_event	[lldbsuite] Remove unused test_event files	2019-10-29 16:56:59 -07:00
__init__.py
.clang-format