This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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:
On 11/18/10 12:34, Bernd Schmidt wrote:
Ideally we'd allocate the valuable ones only to reloads which we know
we'll want to inherit in the future.
True. But that means knowing the set of reloads for future insns.
We do know that - every chain has its own copy of the rld array.
I know I looked at the reload chain, but somehow I missed the rld array.

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.

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.
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.



Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]