combine two load insns

[Jeff Law]

On 12/08/10 01:40, Frederic Riss wrote:
> On 8 December 2010 00:12, Jeff Law<law@redhat.com>  wrote:
>> On 12/07/10 12:29, Frédéric RISS wrote:
>>> Le mardi 07 décembre 2010 à 06:18 -0700, Jeff Law a écrit :
>>>> On 12/06/10 15:07, Ian Lance Taylor wrote:
>>>> Given the two loads don't have a def-use data dependency combine won't
>>>> ever get the opportunity to do anything with them.  In general there is
>>>> no pass which combines insns without a true data dependency and targets
>>>> which have such insns have had to handle those combinations in machine
>>>> dependent reorg.  In fact, it was the combination of independent insns
>>>> which led to the introduction of the machine dependent reorg pass eons
>>>> ago.
>>> The issue with this approach is that reorg runs very late. I suppose
>>> that if one wants to combine 2 SI loads into a DI load, it needs to be
>>> done before IRA to satisfy the generated register constraints.
>> Constraints aren't checked until after register allocation is complete --
>> they're going to be of no help in performing this optimization.  Right now
>> the machine dependent reorg pass or a peephole are the only places this
>> optimization can be performed.    However, I believe it would be possible to
>> make the scheduler perform this optimization with some work.
> Sorry, I think I wasn't clear. I didn't mean constraints in term on
> RTL template constraints, but 'constraints' coming from the new DI
> destination of the load. More specifically: 2 SI loads can target
> totally independent registers whereas a standard DI load must target a
> contiguous SI register pair. If you don't do that before IRA, it will
> most likely be impossible to do cleanly, won't it?
I tend to look at it the other way -- prior to allocation & reload 
you're going to have two SImode pseudos and there's no way to guarantee 
they'll end up in consecutive hard registers.  You'd have to create a 
new DImode pseudo as the destination of the memory load, then copy from 
the DImode pseudo into the two SImode pseudos and rely on the register 
allocator to allocate the DImode pseudo to the same hard registers as 
the two SImode pseudos.  There's no guarantee that'll happen (it often 
will, but in the cases where it doesn't you end up with useless copies).

With that in mind, I tend to see the right way to address this 
optimization as an optimization which runs *after* register allocation 
and reloading where we know the precise set of registers used and thus 
can determine if two SImode loads target a pair of consecutive registers 
and thus are potential candidates for merging the SImode loads into a 
DImode load.  The difficulty here is the data dependency analysis, thus 
my suggestion that the scheduler's dependency analysis be used to drive 
this optimization.

jeff
> Fred