Vladimir Makarov <vmaka...@redhat.com> writes: > On 2/3/25 1:20 AM, H.J. Lu wrote: >> commit 3b9b8d6cfdf59337f4b7ce10ce92a98044b2657b >> Author: Surya Kumari Jangala <jskum...@linux.ibm.com> >> Date: Tue Jun 25 08:37:49 2024 -0500 >> >> ira: Scale save/restore costs of callee save registers with block >> frequency >> >> scales the cost of saving/restoring a callee-save hard register in epilogue >> and prologue with the entry block frequency, which, if not optimizing for >> size, is 10000, for all targets. As the result, callee-saved registers >> may not be used to preserve local variable values across calls on some >> targets, like x86. Add a target hook for the callee-saved register cost >> scale in epilogue and prologue used by IRA. The default version of this >> target hook returns 1 if optimizing for size, otherwise returns the entry >> block frequency. Add an x86 version of this target hook to restore the >> old behavior prior to the above commit. > > This is a complicated problem resulted in many tries to fix it in some > general way. > > In general I am agree with Surya's approach to scale cost of reg > saves/restores somehow. But the general approach, although solved some > problems, also created a lot of new ones. May be because IRA does not > take some other aspects of using callee saved regs. And some of them > were addressed by other patches. e.g. recently proposed by Surya and one > for PR118497. > > I also agree with Richard Sandiford's comment that we should avoid > introducing the new hooks for RA and I actually tried to stick to this > policy for a long time. But I don't see another solution to introducing > the new hook in this case. It is hard to figure out generally in RA > that saves/restores will be insns different from ld/st (e.g. x86 > push/pop) and that they will be cheaper. > > So after some time to think about the patch I decided to approve the RA > part of the patch. I also hope that the work on this problem will > continue (e.g. improving default and target hook implementations and > documentation how to better use it).
For the record, I strongly object to this. The hook just seems like a complete hack to me. Even if we accept that there is target-specific information in play, the hook isn't providing that information. In contrast to what you said above, my objection isn't to having hooks -- those are often needed and good. What bothers me is that the hook isn't well designed. Hooks should provide information rather than override code by brute force. On the other hand, I accept that you're (rightly!) the maintainer. Thanks, Richard
