Adam Nemet <ane...@caviumnetworks.com> writes: > Richard Henderson writes: >> On 09/01/2009 12:48 PM, Adam Nemet wrote: >> > I see. So I guess you're saying that there is little chance to optimize >> > the >> > loop I had in my previous email ;(. >> >> Not at the rtl level. Gimple-level loop splitting should do it though. >> >> > Now suppose we split late, shouldn't we still assume that data-flow can >> > change >> > later. IOW, wouldn't we be required to use the literal/lituse counting >> > that >> > alpha does? >> >> If you split post-reload, data flow isn't going to change >> in any significant way. >> >> > If yes then I guess it's still better to use MEM_EXPR. MEM_EXPR also has >> > the >> > benefit that it does not deem indirect calls as different when >> > cross-jumping >> > compares the insns. I don't know how important this is though. >> >> It depends on how much benefit you get from the direct >> branch. On alpha it's quite a bit, so we work hard to >> make sure that we can get one, if at all possible. > > Thanks, RTH. > > RichardS, > > Can you comment on what RTH is suggesting? Besides cross-jumping I haven't > seen indirect PIC calls get optimized much, and it seems that splitting late > will avoid the data-flow complications. > > I can experiment with this but it would be nice to get some early buy-in. > > BTW, I have the R_MIPS_JALR patch ready for submission but if we don't need to > worry about data-flow changes then using MEM_EXPR is not necessary.
I guess all three would work, but TBH, I think it's too dangerous to rely on dataflow not changing in an unwanted way. We'd also have to say specifically what that way is, and preferably assert for it somehow. Personally, I like the dataflow approach you said you'd taken originally. It's the kind of thing df was designed to make easy, and we already use df in md_reorg to implement -mr10k-cache-barrier. It should just be a case of making sure that all definitions have the same value. I suppose the danger of using MEM_EXPR is that (in the MIPS case) it isn't technically correct for functions that are initially directed at a lazy-binding stub. It probably wouldn't matter in practice though, since there'll be no lazy-binding stub if the address is ever used in a different way. I don't really have any objections to using MEM_EXPR. Richard
