================
@@ -8309,6 +8316,74 @@ bool
CodeGenPrepare::optimizeExtractElementInst(Instruction *Inst) {
return false;
}
+// Given the instruction Inst, rewrite its discriminator operand Disc if it is
+// a PHI node with all incoming values being @llvm.ptrauth.blend(addr, imm)
+// with the same immediate modifier.
+bool CodeGenPrepare::optimizePtrauthInst(Instruction *Inst, Value *Disc) {
----------------
ojhunt wrote:
This matching is fine for now, but the llvm intrinsic does not require the
parameter to be a pointer. I think the best path forward would be to simply
make the intrinsic match the expected interface? In principle no one should be
emitting `@llvm.ptrauth.blend(i64, (i64)pointer)` (reversing the normal blend
parameters), but maybe we should simply make it not an option to construct the
intrinsic in that order?
That will require clang fixes to remove casts in the codegen, but also would
presumably simplify things as it's removing those casts?
Maybe @ahmedbougacha or @rjmccall know why it is set up like this?
https://github.com/llvm/llvm-project/pull/150226
_______________________________________________
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
