[llvm] [PAC][IR][AArch64] Add "ptrauth(...)" Constant to represent signed pointers. (PR #85738)

[Ahmed Bougacha via llvm-commits]

================
@@ -1008,6 +1008,72 @@ struct OperandTraits<NoCFIValue> : public FixedNumOperandTraits<NoCFIValue, 1> {
 
 DEFINE_TRANSPARENT_OPERAND_ACCESSORS(NoCFIValue, Value)
 
+/// A signed pointer, in the ptrauth sense.
+class ConstantPtrAuth final : public Constant {
+  friend struct ConstantPtrAuthKeyType;
+  friend class Constant;
+
+  ConstantPtrAuth(Constant *Ptr, ConstantInt *Key, ConstantInt *Disc,
+                  Constant *AddrDisc);
+
+  void *operator new(size_t s) { return User::operator new(s, 4); }
+
+  void destroyConstantImpl();
+  Value *handleOperandChangeImpl(Value *From, Value *To);
+
+public:
+  /// Return a pointer signed with the specified parameters.
+  static ConstantPtrAuth *get(Constant *Ptr, ConstantInt *Key,
+                              ConstantInt *Disc, Constant *AddrDisc);
+
+  /// Produce a new ptrauth expression signing the given value using
+  /// the same schema as is stored in one.
+  ConstantPtrAuth *getWithSameSchema(Constant *Pointer) const;
+
+  /// Transparently provide more efficient getOperand methods.
+  DECLARE_TRANSPARENT_OPERAND_ACCESSORS(Constant);
+
+  /// The pointer that is signed in this ptrauth signed pointer.
+  Constant *getPointer() const { return cast<Constant>(Op<0>().get()); }
----------------
ahmedbougacha wrote:

We have generally treated a lot of these sorts of types as value types, and there is little you can do with a mutable `Constant` that you can't with a `const` pointer.  What little you can do is deeply suspicious and not common.
It's certainly reasonable to ask to add `const` variants here and elsewhere, but that comes at the cost of verbosity for arguable utility given the above – either way I'm very specifically trying not to litigate that here or in these PRs ;)   This is just matching the rest of the file, see e.g. `BlockAddress` above

https://github.com/llvm/llvm-project/pull/85738