On Fri, Apr 19, 2013 at 1:08 AM, Martin Jambor <mjam...@suse.cz> wrote: > Hi, > > On Fri, Apr 19, 2013 at 12:37:58AM +0200, Steven Bosscher wrote: >> On Fri, Apr 19, 2013 at 12:09 AM, Martin Jambor wrote: >> > I also have not tried scheduling the hard register copy propagation >> > pass twice and measuring the impact on compile times. Any suggestion >> > what might be a good testcase for that? >> >> I think a better question is when this would be useful in the first >> place, and why. In other words: If you propagate hardregs before >> shrink wrapping, what could be a source of new opportunities after >> shrink wrapping? > > Yes, we also did that and neither I nor Honza could think of any > potential problems there. And of course, I'd also measure how many > statements the second run of the pass changed. I'll probably do that > tomorrow anyway. > >> >> >> The only things I can think of, given the current pass order, are: >> >> * different basic block order due to shrink wrapping >> regcprop's effectiveness depends on the order of the basic blocks >> (unfortunately) >> >> * different basic block contents due to head/tail merging (pass_jump2) >> Head/tail merging extends some basic blocks and shortens others. The >> elongated basic blocks may present new opportunities (regcprop is a >> local pass). >> >> * different basic block contents due to dead store elimination (pass_dse2) >> A removed dead store may also make an address calculation redundant, >> changing the regcprop value chains. >> >> * different basic block contents due to peephole2 >> A peephole2 may present new regcprop opportunities, peephole2 misses >> the context to avoid trivial copies. >> >> >> On the other hand, running regcprop earlier also helps some other >> passes. For example, I think regcprop before jump2 may result in more >> successful head/tail merging attempts by making more input operands >> match, but it could hurt if_after_reload by extending live times of >> registers. >> >> >> But wouldn't it be better to avoid these argument-register pseudos >> being assigned to callee-saved registers? Perhaps splitting the live >> range of the pseudos before the first call on each path will do the >> trick, and let IRA pick the right registers for you instead. > > First, where can I have a look how a live range is split? ;-)
Insert a copy and adjust all dominated uses: (set (new-pseudo old-pseudo)) ... adjust downstream uses of old-pseudo to use new-pseudo ... > But second, if such a call is in a loop (or accessible by more than > one path), I wouldn't it be wrong to do that? To avoid that, I > suppose I might end up doing another shrink-wrapping-like search for > the right edge for prologue and actually coming up with a very similar > result to the propagation and shrink-wrapping preparation. But I'm > willing to try. I suppose splitting life-ranges in general before argument setup might make sense - I see hardreg copyprop as a hack around limitations in register allocation. Note that life-range splitting is undone by regular copy propagation. ISTR IRA splits life-ranges in loop code, so there must be already some helpers that could be used. Vlad? Thanks, Richard. > Thanks a lot, > > Martin >
