[PATCH] D132223: [Assignment Tracking][4/*] Add llvm.dbg.assign intrinsic boilerplate

[Orlando Cazalet-Hyams via Phabricator via llvm-commits]

Orlando created this revision.
Orlando added a project: debug-info.
Herald added a subscriber: hiraditya.
Herald added a project: All.
Orlando requested review of this revision.
Herald added subscribers: llvm-commits, jdoerfert.
Herald added a project: LLVM.

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/62367>. This first series of patches adds documentation, the changes necessary to start emitting and using the new metadata, and updates clang with an option to enable the feature. Working with the new metadata in the middle and back end will come later. There are still a few rough edges but I'm putting these patches up now hoping to get feedback on the design and implementation from the upstream community.

---

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 `DIExpression`s, so as an implementation quirk the `FragmentInfo` for `Variable` is contained within `ValueExpression` only.


https://reviews.llvm.org/D132223

Files:
  llvm/include/llvm/IR/IntrinsicInst.h
  llvm/include/llvm/IR/Intrinsics.td
  llvm/lib/IR/IntrinsicInst.cpp
  llvm/lib/IR/Verifier.cpp
  llvm/test/DebugInfo/Generic/assignment-tracking/roundtrip.ll

-------------- next part --------------
A non-text attachment was scrubbed...
Name: D132223.453957.patch
Type: text/x-patch
Size: 15600 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20220819/94311219/attachment.bin>