[all-commits] [llvm/llvm-project] 47c3fe: [DebugInfo][InstrRef][1/4] Support transformations...

[Jeremy Morse via All-commits]

  Branch: refs/heads/main
  Home:   https://github.com/llvm/llvm-project
  Commit: 47c3fe2a22cf753fd55d08d367fbd817b4dd4a1c
      https://github.com/llvm/llvm-project/commit/47c3fe2a22cf753fd55d08d367fbd817b4dd4a1c
  Author: Jeremy Morse <jeremy.morse at sony.com>
  Date:   2021-07-01 (Thu, 01 Jul 2021)

  Changed paths:
    M llvm/include/llvm/CodeGen/MIRYamlMapping.h
    M llvm/include/llvm/CodeGen/MachineFunction.h
    M llvm/include/llvm/CodeGen/MachineInstr.h
    M llvm/lib/CodeGen/LiveDebugValues/InstrRefBasedImpl.cpp
    M llvm/lib/CodeGen/MIRParser/MIRParser.cpp
    M llvm/lib/CodeGen/MIRPrinter.cpp
    M llvm/lib/CodeGen/MachineFunction.cpp
    M llvm/lib/CodeGen/MachineInstr.cpp
    M llvm/lib/Target/X86/X86FixupBWInsts.cpp
    M llvm/test/DebugInfo/MIR/InstrRef/livedebugvalues_instrref_tolocs.mir
    M llvm/test/DebugInfo/MIR/InstrRef/substitusions-roundtrip.mir
    M llvm/test/DebugInfo/MIR/InstrRef/twoaddr-to-threeaddr-sub.mir
    A llvm/test/DebugInfo/MIR/InstrRef/x86-fixup-bw-inst-subreb.mir

  Log Message:
  -----------
  [DebugInfo][InstrRef][1/4] Support transformations that widen values

Very late in compilation, backends like X86 will perform optimisations like
this:

    $cx = MOV16rm $rax, ...
    ->
    $rcx = MOV64rm $rax, ...

Widening the load from 16 bits to 64 bits. SEeing how the lower 16 bits
remain the same, this doesn't affect execution. However, any debug
instruction reference to the defined operand now refers to a 64 bit value,
nto a 16 bit one, which might be unexpected. Elsewhere in codegen, there's
often this pattern:

    CALL64pcrel32 @foo, implicit-def $rax
    %0:gr64 = COPY $rax
    %1:gr32 = COPY %0.sub_32bit

Where we want to refer to the definition of $eax by the call, but don't
want to refer the copies (they don't define values in the way
LiveDebugValues sees it). To solve this, add a subregister field to the
existing "substitutions" facility, so that we can describe a field within
a larger value definition. I would imagine that this would be used most
often when a value is widened, and we need to refer to the original,
narrower definition.

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