This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Help with implementing Wine optimization experiment
- From: André Hentschel <nerv at dawncrow dot de>
- To: gcc at gcc dot gnu dot org
- Date: Mon, 15 Aug 2016 13:35:50 +0200
- Subject: Re: Help with implementing Wine optimization experiment
- Authentication-results: sourceware.org; auth=none
- References: <af89a465-e41f-e560-b27e-8c1e65cceb6a@pobox.com>
Am 14.08.2016 um 08:23 schrieb Daniel Santos:
> I'm experimenting with ways to optimize wine (x86 target only) and I believe I can shrink wine's total text size by around 7% by outlining the lengthy pro- and epilogues required for ms_abi functions making sysv_abi calls. Theoretically, fewer instruction cache misses will offset the extra 4 instructions per function and result in a net performance gain. However, I'm new to the gcc project and a novice x86 assembly programmer as well (have been wanting to work on gcc for a while now!) In short, I want to:
>
> 1. Replace the prologue that pushes di, sp and xmm6-15 with a single call to a global "ms_abi_push_regs" routine
> 2. Replace the epilogue that pops these regs with a jmp to a global "ms_abi_pop_regs" routine
> 3. Add the two routines somewhere so that they are linked into the output.
>
> I have this working in a small-scale experiment (writing the ms_abi function in assembly), but I'm not certain how I would add these routines. Should I make them built-ins?
>
> I have found the code that adds the clobber RTL instructions in ix86_expand_call() (gcc/config/i386/i386.c:25832), and I see that thread_prologue_and_epilogue_insns() (gcc/function.c) is where these clobbers are expanded into the prologue and epilogue, but I'm not sure what the cleanest way to convert this is. My thought was to replace the clobber_reg() calls with one that would add an insn_call, or would it be better to do this in thread_prologue_and_epilogue_insns() where prologue and epilogue generation belongs? But that function is for all targets. Any pointers greatly appreciated!
>
Hi,
Thanks for working on this, but I haven't seen some discussion on wine-devel recently.
I'm also not an expert on that area, but isn't this risking to break copy protections and hotpatching.
Just wanted to remind you about those two things, so the implementation will be usefull.