diff options
author | Jessica Clarke <jrtc27@jrtc27.com> | 2024-10-30 03:27:48 +0000 |
---|---|---|
committer | GitHub <noreply@github.com> | 2024-10-30 03:27:48 +0000 |
commit | 9467645547f99ba8fa8152d514f06e76e0be8585 (patch) | |
tree | 252dc5be6cdd79de57581f74c1edaad77dc08086 /llvm/lib/CodeGen/MachineFunctionAnalysis.cpp | |
parent | e8b7f53fa4dc8a9f74a3d67dfb89eb68fcd78679 (diff) | |
download | llvm-9467645547f99ba8fa8152d514f06e76e0be8585.zip llvm-9467645547f99ba8fa8152d514f06e76e0be8585.tar.gz llvm-9467645547f99ba8fa8152d514f06e76e0be8585.tar.bz2 |
[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
Diffstat (limited to 'llvm/lib/CodeGen/MachineFunctionAnalysis.cpp')
0 files changed, 0 insertions, 0 deletions