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