atrosinenko wrote: @kovdan01 Considering incorrectly choosing the scratch register, I doubt I can implement a test that is reliable: with my particular fix, it would require crafting an example that is *likely* to be emitted as an `AUTH_TCRETURN*` with AddrDisc operand being x16. I cannot simply write an MIR input with x16 being AddrDisc as it is explicitly prohibited by edaae6a75879a38ffe8cd4e064aa9aca77126ef3. I guess I can write an input with some registers being allocated and some not (such as with copy from x16 to a virtual register being AddrDisc) and start the pipeline before register allocator pass, but this looks like overengineering. Or I could use your example as an LLVM IR input, but the test could pass for a lot of other reasons then. So let's consider this being tested by compiling a lot of sources by an assertion-enabled build of LLVM :)
On the other hand, restricting the second operand can be questionable. Maybe it is better to place the destination operand to an "unsafe" register as it is kind of "inherently untrusted" before authentication, but this is not suitable for `AUTH_TCRETURN_BTI`. Having two similar instructions with drastically different restrictions on their operands seems quite strange, so I just assume that usage of "safe" x16 and x17 registers outside of PAuth pseudos is not guaranteed anyway. https://github.com/llvm/llvm-project/pull/110705 _______________________________________________ llvm-branch-commits mailing list llvm-branch-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
