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. 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
