[clang] [clang-tools-extra] [PAC][clang] Define `PointerAuthQualifier` and `PointerAuthenticationMode` (PR #84384)

[John McCall via cfe-commits]

rjmccall wrote:

> Ah, okay, thank you! I had two concerns, but I think neither are valid now that I better understand how `ExtQuals` works: 1) I thought we were increasing the in-memory size of `Qualifiers` in a way that matter (like `SplitQualType`, `ExtProtoInfo` primarily),

AFAIK, `SplitQualType` is never stored long-term.  I'd forgotten that `Qualifiers` was used directly in `ExtProtoInfo` (address-space-qualified methods!), but as it happens, `ExtProtoInfo` is *also* not stored long-term: `FunctionProtoType` reassembles it from its internal storage, and it has the same fast-qualifiers vs. extended-qualifiers optimization as `QualType` where it uses a trailing `Qualifiers` as the slow case.  So this should only increase memory overhead for C++ methods with address-space qualifiers, and it's not much overhead even there.  (IIRC, none of the other extended qualifiers apply to methods — `__ptrauth` could, actually, but we currently restrict it from appearing in parameter positions.)

> 2) I thought we had 32-bit builds of Clang so all the places where we pass/return a `Qualifiers` would require passing in multiple registers now.

I'm sure we still have 32-bit builds of Clang, and yeah, they're going to be incrementally slower as `Qualifiers` grows.  I think we just have to eat that micro cost, though; most of the operations on `Qualifiers` are doing set-algebra-ish operations that  forcing a heap allocation would really punish.  If we're passing and returns `Qualifiers` by value a lot in tight code, we should consider whether we can avoid that, but the micro cost should vanish in the noise typically.

We're somewhat "saved" here by the fact that many 32-bit ABIs are quite bad.  For example, the SysV x86 calling convention always returns structs indirectly, no matter how small they are.

> Do you think the performance concerns are sufficient to warrant doing this optimization work up front? .25% is big enough to warrant concern, but not big enough to need to ask for onerous efforts.

I personally don't think so, no.  But this patch upstreams an overhead we've been eating at Apple for about 7 years, so one could argue that it's easy for me to say that.  It's not unreasonable for you to ask for an investigation to see if we can identify any localized source of the slowdown.  If it's across-the-board (which at .25%, I'd say it probably is, but you never know), maybe we just have to accept it.

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