[all-commits] [llvm/llvm-project] c37f29: [Assignment Tracking][4/*] Add llvm.dbg.assign int...

[Orlando Cazalet-Hyams via All-commits]

  Branch: refs/heads/main
  Home:   https://github.com/llvm/llvm-project
  Commit: c37f29c49ea237eaf65dd137bffc1f3316f82951
      https://github.com/llvm/llvm-project/commit/c37f29c49ea237eaf65dd137bffc1f3316f82951
  Author: OCHyams <orlando.hyams at sony.com>
  Date:   2022-11-07 (Mon, 07 Nov 2022)

  Changed paths:
    M llvm/include/llvm/IR/IntrinsicInst.h
    M llvm/include/llvm/IR/Intrinsics.td
    M llvm/lib/IR/IntrinsicInst.cpp
    M llvm/lib/IR/Verifier.cpp
    M llvm/test/DebugInfo/Generic/assignment-tracking/parse-and-verify/roundtrip.ll
    A llvm/test/DebugInfo/Generic/assignment-tracking/parse-and-verify/verify.ll

  Log Message:
  -----------
  [Assignment Tracking][4/*] Add llvm.dbg.assign intrinsic boilerplate

The Assignment Tracking debug-info feature is outlined in this RFC:

https://discourse.llvm.org/t/
rfc-assignment-tracking-a-better-way-of-specifying-variable-locations-in-ir

Add the llvm.dbg.assign intrinsic boilerplate. This updates the textual-bitcode
roundtrip test to also check that round-tripping with the intrinsic works.

The intrinsic marks the position of a source level assignment.

The llvm.dbg.assign interface looks like this (each parameter is wrapped in
MetadataAsValue, and Value * type parameters are first wrapped in
ValueAsMetadata):

    void @llvm.dbg.assign(Value *Value,
                          DIExpression *ValueExpression,
                          DILocalVariable *Variable,
                          DIAssignID *ID,
                          Value *Address,
                          DIExpression *AddressExpression)

The first three parameters look and behave like an llvm.dbg.value. ID is a
reference to a store. The intrinsic is "linked to" instructions in the same
function that use the same ID as an attachment. That is mostly conceptual at
this point; the two-way link infrastructure will come in another patch. Address
is the destination address of the store and it is modified by
AddressExpression. LLVM currently encodes variable fragment information in
DIExpressions, so as an implementation quirk the FragmentInfo for Variable is
contained within ValueExpression only.

Reviewed By: jmorse

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