On Wed, Jul 02, 2025 at 01:32:37PM +0000, Cui, Lili wrote: > > > + /* Don't mess with the following registers. */ if > > > + (frame_pointer_needed) > > > + bitmap_clear_bit (components, HARD_FRAME_POINTER_REGNUM); > > > > What is that about? Isn't that one of the bigger possible wins? > > Good question!
I know :-) > Initially, I looked at other architectures and disabled the hard frame > pointer, Like aarch? Yeah I always wondered why they don't do it. I decided that that is because of their ABI and architecture stuff they can save and restore their frame reg (r29) with the same insn as they use for the link reg (r30). Of course they could do code to do tradeoffs there, but apparently they did no see the use for that, or perhaps from experience knew what way this would fall in the end. > but after reconsidering, I realized your point makes sense. If the hard frame > pointer were enabled, we would typically emit push %rbp and mov %rsp, %rbp > at the first of prologue, there is no room for separate shrink wrap, but if > the function itself also use rbp, there might be room for optimization, Yup, when using a frame pointer (hard or otherwise, and a very bad plan nowadays, a 1970's thing) you typically get the frame pointer established very first thing, anything that touches the frame needs it after all! But not all code accesses the frame, many early-out paths do not for example. > I took out these two lines and ran some tests, and everything seems fine. I > will do more testing t and try to find a case where the optimization is > really made. For x86 all insns that access the frame explicitly refer to the (hard) frame pointer register I think? So yeah, then things should just work like that :-) Good luck, have fun, don't do cargo-cult, Segher
