On 12/08/10 09:43, Paul Koning wrote:
On Dec 8, 2010, at 11:37 AM, Jeff Law wrote:
On 12/08/10 09:18, Frederic Riss wrote:
OK, I see your point, but I tend to think the the odds of the register
allocator being able to coalesce the additional DI->SI moves in the
pre-IRA approach are by far higher that the odds of having merge
candidates after register allocation.
I agree, but note that failure to coalesce leads to code quality regression.
Also note that handling of double-word values is, IMHO, the allocator's biggest
problem area. This has been greatly helped by Bernd's recent work, but there's
still significant amounts of work to do here.
This probably has been discussed at length in the past, but as a relative
newcomer I'll make this observation... I wonder how much is lost by GCC's
insistence that multi-register values must be in adjacent registers. Obviously
that's hard to change (the registers would have to be explicitly listed instead
of implied by the first register number). And in some cases it is actually
required. But in many cases, it's not (in some machines, never). And I would
think that register allocation could benefit from not having such a
restriction. The item in question here is just one example.
Or get even smarter about splitting up multi-word values into word sized
component values (yes, we're starting to get off-topic here). The
subreg-lowering code does an OK job, but it has certain restrictions
that prevent it from doing a good job. The fundamental problem with
lower-subreg is that it's unable to perform lowering at anything other
than function granularity. If we added the ability to copy-in/copy-out
at regional boundaries we could lower within regions and drastically
reduce the amount of double-word operations left in the IL.
jeff
