This is the mail archive of the
mailing list for the GCC project.
Re: Improving reload inheritance code generation and predictability
- From: Jeff Law <law at redhat dot com>
- To: Bernd Schmidt <bernds at codesourcery dot com>
- Cc: gcc-patches <gcc-patches at gcc dot gnu dot org>
- Date: Fri, 19 Nov 2010 09:18:04 -0700
- Subject: Re: Improving reload inheritance code generation and predictability
- References: <4CE53C3D.firstname.lastname@example.org> <4CE57FC8.email@example.com>
On 11/18/10 12:34, Bernd Schmidt wrote:
On 11/18/2010 03:46 PM, Jeff Law wrote:
Potentially, yes. If we want to go forward, then we probably would need
a PARAM to limit the number of insns scanned.
Isn't this quadratic in the number of insns?
Basically we start searching forward in the stream from the current insn
needing a reload noting uses of spill regs as we go.
True. But that means knowing the set of reloads for future insns.
The further away
from the insn needing reloads the spill reg is used the more desirable
that spill reg becomes. If we can't find all the spill regs before
reaching the end of the block, the remaining spill regs are considered
the most desirable and we allocate these stragglers in the round-robin
Ideally we'd allocate the valuable ones only to reloads which we know
we'll want to inherit in the future.