This is the mail archive of the
mailing list for the GCC project.
Re: Improving reload inheritance code generation and predictability
On 11/19/10 09:22, Bernd Schmidt wrote:
On 11/19/2010 05:18 PM, Jeff Law wrote:
I know I looked at the reload chain, but somehow I missed the rld array.
On 11/18/10 12:34, Bernd Schmidt wrote:
We do know that - every chain has its own copy of the rld array.
True. But that means knowing the set of reloads for future insns.
Ideally we'd allocate the valuable ones only to reloads which we know
we'll want to inherit in the future.
I'm not sure I want to duplicate all the logic to *know* we'll inherit a
reload in a future insn. But we could make a scan of the rld arrays to
determine if a value is a reasonable candidate for inheritance and if
so, try hold its value in a spill reg as long as possible. For
unlikely candidates we'd want to re-use a spill reg already holding an
unlikely inheritance candidate.
That could probably be computed at the start of reload_as_needed. It's
probably O(n^2) where n is the number of reloads within a basic block.
Yea, it's just memory, right :-) The usage could probably be kept to a
minimum by only keeping the distance to next use for spill regs rather
than all hard regs. The scan in allocate_reload_reg then becomes a
qsort. Probably worth investigating.
I guess we could try to add a distance-to-next use array for hard regs
as well, to eliminate the quadratic forward scan at the expense of
higher memory use.