[PATCH] D66935: [AArch64][DebugInfo] Do not recompute CalleeSavedStackSize

Sander de Smalen via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Fri Aug 30 07:09:13 PDT 2019


sdesmalen added a comment.

In D66935#1651499 <https://reviews.llvm.org/D66935#1651499>, @efriedma wrote:

> Why are we calling determineCalleeSaves in LiveDebugValues, anyway?  Can't it just call getCalleeSavedInfo()?
>  Making the determineCalleeSaves computation lazy, like this patch does, is really confusing.


This method seems to be called by several passes:

- LiveDebugValues
- PrologEpilogInserter
- RegUsageInfoCollector
- RegisterScavenging
- ShrinkWrap

The problem with `determineCalleeSaves` is that it does much more than determining the callee-saves:

- It also creates a new StackObject for the emergency spill slot.
- It marks this slot as the scavenging slot in the RegisterScavenger.
- It saves the size of the callee-save area (in AArch64MachineFunctionInfo).

And this behaviour to change state seems somewhat by design, because `RegisterScavenger*` is passed as argument and MachineFunction is not a `const` reference. After PEI, `getCalleeSavedInfo` can be used as you suggest, but one could argue that `determineCalleeSaves` is still a valid interface to use. Perhaps I could add an assert in determineCalleeSaves that suggests using getCalleeSavedInfo if `MFI.isCalleeSavedInfoValid()` is true, but I think that is even more confusing. Perhaps the better way is to not let `determineCalleeSaves` change state at all, but that would require changes to the interface, which is likely to also require changes to other targets. From that point of view, letting `determineCalleeSaves` use the cached information from `getCalleeSavedInfo` seemed sensible.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D66935





More information about the llvm-commits mailing list