"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? Ayal. > Thus, if you wanted to do unconditional load hoisting, the thing to do > is to make a function like do_regular_insertion in tree-ssa-pre.c, and > call it from insert_aux. > > We already have another heuristic for partially antic fully available > expressions, see do_partial_partial_insertion
