On 7/23/20 3:29 PM, Jeff Law wrote: >>> What's driving this change? >> >> Peter noticed IRA allocates stuff to volatile registers while it is life >> through a call, and then LRA has to correct that, not optimal. > I can't recall if IRA or LRA handles the need to save them to the stack, but > the > whole point is you can do much better sometimes by saving into the stack with > the > caller-saves algorithm vs just giving up and spilling. > >> >>> IRA will do a cost/benefit analysis to see using call clobbered registers >>> like >>> this is profitable or not. You're just turning the whole thing off.
Sorry for taking so long to reply. I'm the guilty party for asking Pat to submit the patch. :-) I was not aware IRA did that and just assumed it was a bug. For now, consider the patch withdrawn. That said, I will have to look at that cost computation, especially since when I last looked, IRA does not count potential prologue/epilogue save/restore insns if it were to assign a non-volatile register when computing reg costs. That would seem to be an important consideration here. I'll note this all came about when I was looking at PR96017, which is due to not shrink-wrapping a pseudo. That was due to it being live across a call. I first I thought (for the 2nd test case, not the original one) split_live_ranges_for_shrink_wrap() was nicely splitting the pseudo for us, but it must have been the caller-saves algorithm you mention above. However, that code doesn't handle the original test case, which I think it should. My thought for that bug was to introduce some extra splitting before RA (maybe as part of split_live_ranges_for_shrink_wrap?) where we split pseudos that are live across a call, but that have at least one path to the exit that doesn't cross a call. However, if we can beef up the caller-saves cost computation, maybe that would work too? Peter
