[PATCH] D132384: [AArch64][PAC] Select MOVK for ptrauth.blend intrinsic.

[Ahmed Bougacha via Phabricator via llvm-commits]

ab added inline comments.


================
Comment at: llvm/lib/Target/AArch64/AArch64InstrInfo.td:8410
+
+let Predicates = [HasPAuth] in {
+def : Pat<(int_ptrauth_blend GPR64:$Rd, imm64_0_65535:$imm),
----------------
kristof.beyls wrote:
> It seems that the blend intrinsic can be implemented on cores that do not implement the PAuth extension. Which made me wonder if it should be allowed or not for a user to use the blend intrinsic when targeting a core not supporting PAuth?
> I don't have a very strong argument either way. I wonder if you happen to have an opinion?
> One thing I did think off - but couldn't answer from just looking at this patch - are DAGISel and GISel consistent in rejecting the blend intrinsic when PAuth is not implemented?
> I think it would make sense to have a regression test checking that the blend intrinsic is indeed accepted/rejected as expected when targeting a core that does not support PAuth.
> It seems that the blend intrinsic can be implemented on cores that do not implement the PAuth extension. Which made me wonder if it should be allowed or not for a user to use the blend intrinsic when targeting a core not supporting PAuth?

I don't have a strong argument either, but until we have a use for it on other cores, I'd leave it as disallowed there?
Somewhat related: `XPAC`/`strip` is, however, commonly needed on cores that don't support PAC (or aren't even aarch64), usually for debugging and crash analysis tools.  But that one actually depends on aarch64 processor state (TBI, T0Sz), sadly.

> One thing I did think off - but couldn't answer from just looking at this patch - are DAGISel and GISel consistent in rejecting the blend intrinsic when PAuth is not implemented?

They're not, and I found out by later tests breaking ;)  On SDAG, if we can't match the 16-bit immediate, we'll fallback to the arbitrary GPR64 value (which isn't ideal by itself.)   So we can't easily fail on wider values, at least not without some machinery to match this case (maybe matching any immediate and erroring out when trying to encode;  I'm not sure we can fail in a good way at isel time)


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D132384/new/

https://reviews.llvm.org/D132384