[all-commits] [llvm/llvm-project] 928c33: [DebugInfo] Handle additional types of stores in a...

Stephen Tozer via All-commits all-commits at lists.llvm.org
Tue Apr 22 09:14:48 PDT 2025


  Branch: refs/heads/main
  Home:   https://github.com/llvm/llvm-project
  Commit: 928c33354ee88b98bcf785d8866171857a92dd82
      https://github.com/llvm/llvm-project/commit/928c33354ee88b98bcf785d8866171857a92dd82
  Author: Stephen Tozer <stephen.tozer at sony.com>
  Date:   2025-04-22 (Tue, 22 Apr 2025)

  Changed paths:
    M llvm/lib/CodeGen/AssignmentTrackingAnalysis.cpp
    M llvm/lib/IR/Verifier.cpp
    A llvm/test/CodeGen/RISCV/di-assignment-tracking-vector.ll
    A llvm/test/Verifier/diassignid-vector-stores.ll

  Log Message:
  -----------
  [DebugInfo] Handle additional types of stores in assignment tracking (#129070)

Fixes #126417.

Currently, assignment tracking recognizes allocas, stores, and mem
intrinsics as valid instructions to tag with DIAssignID, with allocas
representing the allocation for a variable and the others representing
instructions that may assign to the variable. There are other intrinsics
that can perform these assignments however, and if we transform a store
instruction into one of these intrinsics and correctly transfer the
DIAssignID over, this results in a verifier error. The
AssignmentTrackingAnalysis pass also does not know how to handle these
intrinsics if they are untagged, as it does not know how to extract
assignment information (base address, offset, size) from them.

This patch adds _some_ support for some intrinsics that may perform
assignments: masked store/scatter, and vp store/strided store/scatter.
This patch does not add support for extracting assignment information
from these, as they may store with either non-constant size or to
non-contiguous blocks of memory; instead it adds support for recognizing
untagged stores with "unknown" assignment info, for which we assume that
the memory location of the associated variable should not be used, as we
can't determine which fragments of it should or should not be used.

In principle, it should be possible to handle the more complex cases
mentioned above, but it would require more substantial changes to
AssignmentTrackingAnalysis, and it is mostly only needed as a fallback
if the DIAssignID is not preserved on these alternative stores.



To unsubscribe from these emails, change your notification settings at https://github.com/llvm/llvm-project/settings/notifications


More information about the All-commits mailing list