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.
At one extreme, we could do all the work necessary to prove that a particular value will be inherited by a later reload (since we know all the reloads and have the insn stream). This would include verifying that the reload reg holding the value won't be clobbered, that we have enough other reload regs available for the intervening reloads so that we wouldn't have the evict the value, etc.

On the other end, if we marked reloads as reused or not-reused based on whether or not the value was used in a later reload in the same block, we could work harder to keep reused reload values available for inheritance and do minimal work on not-reused values. I think this boils down some hash table manipulations just prior to reload_as_neded and further surgery in allocate_reload_reg.

Ultimately, I think both solutions should improve the generated code by allowing us to pick up more inheritance opportunities. I doubt either would be a significant compile-time improvement. I think the question we need to answer is how much effort do we want to put into this code, which I consider long term throw-away.

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.
Based on Vlad & my experiments, the potentially quadratic forward scan isn't a serious issue; we'd want to clamp it to deal with pathological cases if we ultimately chose to integrate these changes, but in practice the DF scan is the bottleneck.


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