On 8/1/07, Ayal Zaks <[EMAIL PROTECTED]> wrote: > "Daniel Berlin" <[EMAIL PROTECTED]> wrote on 01/08/2007 18:27:35: > > > On 8/1/07, Tehila Meyzels <[EMAIL PROTECTED]> wrote: > > > "Daniel Berlin" <[EMAIL PROTECTED]> wrote on 31/07/2007 18:00:57: > > > > > > > > > > > I agree with you for conditional stores/loads. > > > > > > Great! > > > > > > > > > > > The unconditional store/load stuff, however, is exactly what > > > > tree-ssa-sink was meant to do, and belongs there (this is #3 above). > > > > I'm certainly going to fight tooth and nail against trying to > shoehorn > > > > unconditional store sinking into if-conv. > > > > > > Sometimes, store-sinking can cause performance degradations. > > > One reason for that, is increasing register pressure, due to extending > life > > > range of registers. > > > > > > In addition, in case we have a store followed by a branch, store > sinking > > > result will be a branch followed by a store. > > > On some architectures, the former can be executed in parallel, as > opposed > > > to the latter. > > > Thus, in this case, it worth executing store-sinking only when it helps > the > > > if-conversion to get rid of the branch. > > > > > > > > How do you suggest to solve this problem, in case store-sinking will be > > > part of the tree-sink pass? > > > > > Store sinking already *is* part of the tree-sink pass. It just only > > sinks a small number of stores. > > The solution to the problem that "sometimes you make things harder for > > the target" is to fix that in the backend. In this case, the > > scheduler will take care of it. > > > > All of our middle end optimizations will sometimes have bad effects > > unless the backend fixes it up. Trying to guess what is going to > > happen 55 passes down the line is a bad idea unless you happen to be a > > very good psychic. > > > > As a general rule of thumb, we are happy to make the backend as target > > specific and ask as many target questions as you like. The middle > > end, not so much. There are very few passes in the middle end that > > can/should/do ask anything about the target. Store sinking is not one > > of them, and I see no good reason it should be. > > > > > Another point, what about (unconditional) load hoisting: > > > It's surely not related to sink pass, right? > > > > > PRE already will hoist unconditional loads out of loops, and in places > > where it will eliminate redundancy. > > > > It could also hoist loads in non-redundancy situations, it is simply > > the case that it's current heuristic does not think this is a good > > idea. > > > > Hoisting a non-redundant load speculatively above an if may indeed be a bad > idea, unless that if gets converted as a result (and possibly even then > ...). Are we in agreement then that unconditional load/store motion for > the sake of redundancy elimination continues to belong to PRE/tree-sink, > and that conditional load/store motion for the sake of conditional-branch > elimination better be coordinated by if-cvt? >
Yes. My only issue here is duplication of code that exists in other passes, not one of who/when/why things get done. IE it is easier to use PRE's infrastructure to do the unconditional load elimination, but still only do more than redundancy elimination when you will if-convert branches, then it would be to write a new pass. Your new pass would end up probably missing loads that PRE goes to trouble to get, and would duplicate a lot of the safety computation PRE already knows how to do. Of course, if you only see yourself moving 1 or two loads per function, it may be quicker to do just those in their own pass controlled by ifcvt. But if you are going to try to if-convert every branch, and every load inside those branches, you really don't want to try to make your computation as efficient as PRE makes it. A similar situation exists for unconditional store sinking/tree-ssa-sink.
