[PATCH] D42534: [mips] Compute MaxCallFrame size early on

[Matthias Braun via Phabricator via llvm-commits]

MatzeB added a comment.

In https://reviews.llvm.org/D42534#990357, @sdardis wrote:

> +CC'ing @MatzeB for additional insight on what needs to be changed.
>
> Found the bug. What's occurring with the debug information test failures with this patch, is that during the insertion of debug instructions for function arguments, it has to determine which register to assign to the debug instruction, see SelectionDAGISel.cpp:505. Here it asks for the frame pointer register which for some RISC like targets by the size of the frame for the function.
>
> It seems to me that we need to compute the max call frame size before that point (SelectionDAGISel.cpp:505) for targets which use call frame setup and destroy pseudo instructions, this however requires changes for every target which implements finalizeLowering() to compute the maxCallFrameSize.


Yeah code calling hasFP() early in the process is a real annoyance. You can find me wiggling in the review of https://reviews.llvm.org/D32622 too. At the time it seemed to me like it only influences scheduling heuristic so I went with this hack in the ARM target:

  // hasFP ends up calling getMaxCallFrameComputed() which may not be
  // available when getPressureLimit() is called as part of
  // ScheduleDAGRRList.
  bool HasFP = MF.getFrameInfo().isMaxCallFrameSizeComputed()
               ? TFI->hasFP(MF) : true;

instead.

But it looks like you found a bigger problem than the heuristic. If you can find ways for ISel to not do this anymore I would certainly apreciate it!


https://reviews.llvm.org/D42534