[all-commits] [llvm/llvm-project] 66d03a: [DebugInfo][dexter] Add dexter tests for escaped l...

[Orlando Cazalet-Hyams via All-commits]

  Branch: refs/heads/master
  Home:   https://github.com/llvm/llvm-project
  Commit: 66d03af88c2e4932ae53787e07f502b90ab220cc
      https://github.com/llvm/llvm-project/commit/66d03af88c2e4932ae53787e07f502b90ab220cc
  Author: OCHyams <orlando.hyams at sony.com>
  Date:   2020-10-26 (Mon, 26 Oct 2020)

  Changed paths:
    A debuginfo-tests/dexter-tests/memvars/bitcast.c
    A debuginfo-tests/dexter-tests/memvars/const-branch.c
    A debuginfo-tests/dexter-tests/memvars/ctrl-flow.c
    A debuginfo-tests/dexter-tests/memvars/implicit-ptr.c
    A debuginfo-tests/dexter-tests/memvars/inlining-dse.c
    A debuginfo-tests/dexter-tests/memvars/inlining.c
    A debuginfo-tests/dexter-tests/memvars/loop.c
    A debuginfo-tests/dexter-tests/memvars/ptr-to.c
    A debuginfo-tests/dexter-tests/memvars/struct-dse.c

  Log Message:
  -----------
  [DebugInfo][dexter] Add dexter tests for escaped locals

Recently there has been renewed interest in improving debug-info for variables
that (partially or otherwise) live on the stack in optimised code.

At the moment instcombine speculates that stack slots are probably going to be
promoted to registers, and prepares the debug-info accordingly. It runs a
function called LowerDbgDeclare which converts dbg.declares to a set of
dbg.values after loads, and before stores and calls. Sometimes the stack
location remains (e.g. for escaped locals). If any dbg.values become undef
where the stack location is still valid we end up unnecessarily reducing
variable location coverage due to our inability to track multiple locations
simultaneously. There is a flag to disable this feature
(-instcombine-lower-dbg-declare=0), which prevents this conversion at the cost
of sometimes providing incorrect location info in the face of DSE, DCE, GVN,
CSE etc.

This has been discussed fairly extensively on PR34136.

The idea of these tests is to provide examples of situations that we should
consider when designing a new system, to aid discussions and eventually help
evaluate the implementation.

Dexter isn't ideal for observing specific optimisation behaviour. Writing an
exaustive test suite would be difficult, and the resultant suite would be
fragile. However, I think having some concrete executable examples is useful
at least as a reference.

Differential Revision: https://reviews.llvm.org/D89543