On 8 December 2010 15:39, Jeff Law <l...@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
