This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH] [i386] Recompute the frame layout less often
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.santos@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.
>