Hi Daniel, there is one thing I don't understand in your patch: That is, it introduces a static value:
/* Registers who's save & restore will be managed by stubs called from pro/epilogue. */ static HARD_REG_SET GTY(()) stub_managed_regs; This seems to be set as a side effect of ix86_compute_frame_layout, and depends on the register usage of the current function. But values that depend on the current function need usually be attached to cfun->machine, because the passes can run in parallel unless I am completely mistaken, and the stub_managed_regs may therefore be computed from a different function. Bernd. On 05/14/17 12:25, Uros Bizjak wrote: > On Sun, May 14, 2017 at 11:16 AM, Daniel Santos <daniel.san...@pobox.com> > wrote: >> On 05/14/2017 02:42 AM, Bernd Edlinger wrote: >>> >>> Hi, >>> >>> >>> this patch uses the new TARGET_COMPUTE_FRAME_LAYOUT hook in the i386 >>> backend to avoid re-computing the frame layout when not really >>> necessary. >>> >>> It simplifies the logic in ix86_compute_frame_layout by removing >>> the use_fast_prologue_epilogue_nregs, which is no longer necessary, >>> because the frame layout can no longer change spontaneously. >>> >>> >>> Bootstrapped and reg-tested on x86_64-pc-linux-gnu. >>> Is it OK for trunk? >>> >>> >>> Thanks >>> Bernd. >> >> >> I think Uros is about to commit my improvements to ms to sysv abi calls, >> which is a large change and will conflict with your patch. I've added >> several new fields to struct ix86_frame that will need to be merged (and >> moved to i386.h). I believe that my only explicit check of >> crtl->stack_realign_finalized is during pro/epilogue expand, and not in >> ix86_compute_frame_layout. A former incarnation of my patches needed >> ix86_compute_frame_layout to be called *after* it was set, but I believe >> that is no longer the case, and so shouldn't conflict, but retesting should >> certainly be done. > > Yes, the mcall-ms2sysv-xlogues patch was committed to mainline, please > re-test and re-send the patch. > > Uros. >