If you want to check for all uses of PAC, the SpillsLR argument to
shouldSignReturnAddress should be true instead of false, as that value will be
returned from the function if the other checks fall through.
Details
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
llvm/lib/Target/ARM/ARMFrameLowering.cpp | ||
---|---|---|
1814 | Can we use MF.getInfo<ARMFunctionInfo>()->shouldSignReturnAddress() instead (i.e. base the decision on whether or not the function actually spills LR)? Or is there a pass later in the pipeline that can transform the function in such a way that it starts spilling LR? |
Yea, good point. I amended the patch.
I don't think we should worry about a pass spilling the LR and we don't do that anywhere else in the code. Practically shrinkwrapping is adjacent to the prolog/epilog inserter where we make the decision to insert PACs.
LGTM, but please update the commit message. The part saying
SpillsLR argument to shouldSignReturnAddress should be true instead of false
No longer describes the actual change in the code.
I did some more testing, and unfortunately we can't rely on LRSpilled being set correctly.
LRSpilled is being set by ARMFrameLowering::determineCalleeSaves, which is called a couple of times throughout the code. I experimented a bit, and it's a bit dirty to call it from within enableShrinkWrapping, as you need to cast away the const on MachineFunction, and it's a very big slab of code that clearly triggers some side effect (besides setting LRSPilled) as calling it here will make some tests fail. Looking at the failed tests (not just PACBTI tests) it doesn't look like anything wrong is going on, but it's all a bit too icky for my taste.
So I reverted to the previous state, as it's not worth the time-effort to possibly eek out a slight performance edge for a temporary stop-gap which we'll remove once we fix the issue proper. I feel I already spent a bit too much time on this.
OK, in this case, it makes sense to be conservative and disable shrink-wrapping for all functions that use PAC. LGTM.
Can we use MF.getInfo<ARMFunctionInfo>()->shouldSignReturnAddress() instead (i.e. base the decision on whether or not the function actually spills LR)? Or is there a pass later in the pipeline that can transform the function in such a way that it starts spilling LR?