[PATCH] D92469: [ARM] harden-sls-blr: avoid r12 and lr in indirect calls

[Kristof Beyls via Phabricator via llvm-commits]

kristof.beyls marked 2 inline comments as done.
kristof.beyls added inline comments.


================
Comment at: llvm/lib/Target/ARM/ARMInstrInfo.td:2498
                 [(ARMcall GPR:$func)]>,
-            Requires<[IsARM, HasV5T]>, Sched<[WriteBrL]> {
+            Requires<[IsARM, HasV5T, NoSLSBLRMitigation]>, Sched<[WriteBrL]> {
     bits<4> func;
----------------
ostannard wrote:
> Wouldn't this also prevent use of the BLX instructions in inline assembly? I think it would be better to leave the requirements on the instructions as they are, and move the isel patterns out into separate `Pattern` records, which can have their own target requirements. I looks like that is already how the AArch64 backend does this.
Agreed, I have separated out the patterns here and also in the Thumb instruction variants.
I also added a test to the test file that checks that "blx r12" is accepted if used in inline assembly.


================
Comment at: llvm/test/CodeGen/ARM/speculation-hardening-sls.ll:195
+; The below test carefully increases register pressure to persuade code
+; generation to produce an indirect call using r12 or lr. Yes, that is a bit
+; fragile.
----------------
ostannard wrote:
> A slightly less fragile way to do this would be to pass the function pointer into and out an inline asm statement, with an output constraint which forces it into r12/lr. The compiler can still move it to a different register (and will need to do that with slsblr enabled), but it won't be dependent on register allocation order.
Thanks for the suggestion, that is indeed better.
Now implemented.


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

https://reviews.llvm.org/D92469