[all-commits] [llvm/llvm-project] 946764: [CodeGen] Rename MVT::iPTRAny to MVT::pAny

[Jessica Clarke via All-commits]

  Branch: refs/heads/main
  Home:   https://github.com/llvm/llvm-project
  Commit: 9467645547f99ba8fa8152d514f06e76e0be8585
      https://github.com/llvm/llvm-project/commit/9467645547f99ba8fa8152d514f06e76e0be8585
  Author: Jessica Clarke <jrtc27 at jrtc27.com>
  Date:   2024-10-30 (Wed, 30 Oct 2024)

  Changed paths:
    M llvm/include/llvm/CodeGen/ValueTypes.h
    M llvm/include/llvm/CodeGen/ValueTypes.td
    M llvm/include/llvm/CodeGenTypes/MachineValueType.h
    M llvm/include/llvm/IR/Intrinsics.h
    M llvm/include/llvm/IR/Intrinsics.td
    M llvm/lib/Target/NVPTX/NVPTXInstrInfo.td
    M llvm/utils/TableGen/Common/CodeGenDAGPatterns.cpp
    M mlir/tools/mlir-tblgen/LLVMIRIntrinsicGen.cpp

  Log Message:
  -----------
  [CodeGen] Rename MVT::iPTRAny to MVT::pAny

Whilst in upstream LLVM iPTRAny is only ever an integer, essentially an
alias for iPTR, this is not true in CHERI LLVM, where it gets used to
mean "iPTR or cPTR", i.e. either an integer address or a capability
(with cPTR and cN being the capability equivalents of iPTR and iN).
Moreover, iPTRAny is already not itself regarded as an integer (calling
isInteger() will give false), so the "i" prefix is misleading, and it
stands out as different from all the other xAny that have a single
letter prefix denoting their type.

Thus, rename it to pAny, reflecting that it is an overloaded pointer
type, which could end up being specialised to an integer type, but does
not have to be.

This has been verified to have no effect on the generated files for LLVM
itself or any in-tree target beyond the replacement of the identifier
iPTRAny with pAny in GenVT.inc.

Reviewers: arsenm

Reviewed By: arsenm

Pull Request: https://github.com/llvm/llvm-project/pull/113733



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