[PATCH] D69097: [AArch64][MachineOutliner] Return address signing for outlined functions
    David Tellenbach via Phabricator via llvm-commits 
    llvm-commits at lists.llvm.org
       
    Thu Oct 17 06:12:45 PDT 2019
    
    
  
tellenbach added a comment.
In D69097#1712743 <https://reviews.llvm.org/D69097#1712743>, @ostannard wrote:
> It looks like you're emitting PAC instructions but not AUT, so I'd expect this to fault when the outlined function returns. Or is some other code already returning using RETAA/RETAB? In which case, the test should check that.
Yep! AUT instructions are inserted during epilogue emission (again frame lowering). I'll fix that.
> If our callees have `"sign-return-address"="non-leaf"`, I think we should inherit that in the outlined function, meaning that we only need PAC/AUT instructions if the outlined function spills LR.
So, if `a`, `b` and `c` participate in outlining, `a` and `b` have `sign-return-address=all` and `c` has `sign-return-address=non-leaf`, the new outlined function should behave like having `sign-return-address=non-leaf`? Or should we only allow outlining if the attributes match?
> Emitting no signing instructions when the callees have mismatched keys seems dangerous, maybe we should consider these candidates to be incompatible, and only outline from functions with matching return address signing options?
Sure, that would be certainly the safest possibility. This could include the key types as well as the overall outlining options (see comment above).
> This is going to add one or two instructions (depending on whether we use RETAA/RETAB) to each outlined function which needs them, which we should consider when deciding if outlining is worth it, otherwise this might end up increasing code size.
That's a good point. IIRC the machine outliner already provides functionality for measuring "frame overhead".
Repository:
  rG LLVM Github Monorepo
CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D69097/new/
https://reviews.llvm.org/D69097
    
    
More information about the llvm-commits
mailing list