On 7/31/07, Tehila Meyzels <[EMAIL PROTECTED]> wrote: > > Hi, > > I'd like to bring up on the list a discussion that a bunch of people (most > of those CC-ed above) started at the GCC Summit: > > Lately, there were few efforts, that are not necessarily related to each > other, but are all relevant to if-conversion. > Each of them has its own restriction, like a specific control-flow, target > dependent information, permission to transform speculative loads, etc. > > Few patches that I'm aware of are: > 1. Conditional store sinking, by Michael Matz: > http://gcc.gnu.org/ml/gcc-patches/2007-04/msg00724.html > > 2. If -conversion for multiple IF_THEN_ELSE clauses, by Victor Kaplansky: > http://gcc.gnu.org/ml/gcc-patches/2006-05/msg00265.html > Also mentioned here: http://gcc.gnu.org/wiki/AutovectBranchOptimizations > (2.3.3) > > 3. (unconditional) Store sinking (4.1.1 based), by Revital Eres and Victor > Kaplansky: > http://gcc.gnu.org/ml/gcc-patches/2006-05/msg00265.html (same patch as > previous) > Also mentioned here: http://gcc.gnu.org/wiki/AutovectBranchOptimizations > (2.3.2) > > 4. Conditional load hoisting (4.1.1 based), by myself: > http://gcc.gnu.org/ml/gcc-patches/2007-07/msg02168.html > > 5. Maybe more? > > You're welcome to share your/others related works here... > > > I'd like to suggest to converge all these efforts into a single improved > tree-level if-conversion pass (i.e., on the top of tree-if-conv.c). > Currently, the tree-level if-conversion pass is quite limited in several > ways, and mostly with respect to handling of loads/stores (it basically > doesn't handle them), but not only. > > There are several reasons why to store-sinking and load-hoisting should be > combined with the if-conversion pass: > 1. Store-sinking/load hoisting effect one another and they both can create > new opportunities for if-conversion (not only in vectorizable loops, for > example).
> Currently, load-store motion pass happens too late and thus don't help > the (tree-ssa) if-converter. > 2. Store-sinking/load hoisting may have an overhead and may degrade > performance unless the relevant conditional branch gets if-converted. I agree with you for conditional stores/loads. 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.
