[all-commits] [llvm/llvm-project] bfadc5: [DebugInfo][InstrRef] Cope with win32 calls changi...

[Jeremy Morse via All-commits]

  Branch: refs/heads/main
  Home:   https://github.com/llvm/llvm-project
  Commit: bfadc5dcbfa81da00b58de5e62b569faf24538e7
      https://github.com/llvm/llvm-project/commit/bfadc5dcbfa81da00b58de5e62b569faf24538e7
  Author: Jeremy Morse <jeremy.morse at sony.com>
  Date:   2021-11-24 (Wed, 24 Nov 2021)

  Changed paths:
    M llvm/include/llvm/CodeGen/TargetFrameLowering.h
    M llvm/lib/CodeGen/LiveDebugValues/InstrRefBasedImpl.cpp
    M llvm/lib/CodeGen/LiveDebugValues/InstrRefBasedImpl.h
    M llvm/lib/Target/X86/X86FrameLowering.cpp
    M llvm/lib/Target/X86/X86FrameLowering.h
    A llvm/test/DebugInfo/MIR/InstrRef/win32-chkctk-modifies-esp.mir

  Log Message:
  -----------
  [DebugInfo][InstrRef] Cope with win32 calls changing SP in LiveDebugValues

Almost all of the time, call instructions don't actually lead to SP being
different after they return. An exception is win32's _chkstk, which which
implements stack probes. We need to recognise that as modifying SP, so
that copies of the value are tracked as distinct vla pointers.

This patch adds a target frame-lowering hook to see whether stack probe
functions will modify the stack pointer, store that in an internal flag,
and if it's true then scan CALL instructions to see whether they're a
stack probe. If they are, recognise them as defining a new stack-pointer
value.

The added test exercises this behaviour: two calls to _chkstk should be
considered as producing two different values.

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