Re: combine two load insns

[Frederic Riss <frederic dot riss at gmail dot com>]

On 8 December 2010 15:39, Jeff Law <law@redhat.com> wrote:
> On 12/08/10 01:40, Frederic Riss wrote:
>> 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.

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 with your suggestion of
being able to do that in the scheduler though, it might be a good fit,
even if it's not a scheduling issue in the first place.

Fred