Marc Glisse <marc.gli...@inria.fr> wrote: >On Fri, 19 Jul 2013, Jeff Law wrote: > >> It's also worth noting that fold-const.c also does some type >> hoisting/sinking. > >fold-const.c does everything ;-) > >> Ideally that code should just be going away. > >Like most of the code from fold-const.c that isn't about folding >constants, I guess, once it has a replacement at the gimple level. > >>>>> If I understand, the main reason is because you want to go through >the >>>>> statements in reverse order, since this is the way the casts are >being >>>>> propagated (would forwprop also work, just more slowly, or would >it miss >>>>> opportunities across basic blocks?). >>>> It would miss some opportunities, >>> >>> Could you explain in what case? I guess my trouble understanding >this is >>> the same as in the next question, and I am missing a fundamental >point... >> Anytime you hoist/sink a cast, you're moving it across an operation >-- which >> can expose it as a redundant cast. >> >> Let's say you start with >> >> A = (T) x1; >> B = (T) x2; >> R = A & B; >> >> >> And sink the cast after the operation like this: >> >> C = x1 & x2; >> R = (T) C; >> >> We may find that that cast of C to type T is redundant. Similar >cases can be >> found when we hoist the cast across the operation. I saw this kind >of >> situation occur regularly when I was looking at Kai's >hoisting/sinking >> patches. > >IIRC the question here was how forwprop could miss opportunities that a > >backward (reverse dominance) walk finds, and I don't see that in this >example. If the cast is redundant, forwprop is just as likely to detect > >it. > >> Now I believe one of Kai's goals is to allow our various pattern >based >> folders to work better by not having to account for casting >operations as >> often in sequences of statements we want to fold. > >Ah. I thought it was mostly so operations would be performed in a >smaller, >hopefully cheaper mode. Simplifying combiner patterns would be nice if >that worked. > >>>> That's a real good question; I find myself looking a lot at the >bits >>>> in forwprop and I'm getting worried it's on its way to being an >>>> unmaintainable mess. Sadly, I'm making things worse rather than >>>> better with my recent changes. I'm still hoping more structure >will >>>> become evident as I continue to work through various improvements. >>> >>> It looks to me like a gimple version of fold, except that since it >is >>> gimple, basic operations are an order of magnitude more complicated. >But >>> I don't really see why that would make it an unmaintainable mess, >giant >>> switches are not that bad. >> It's certainly moving towards a gimple version of fold and special >casing >> everything as we convert from fold and to gimple_fold (or whatever we >call >> it) is going to result in a horrid mess. >> >> I find myself thinking that at a high level we need to split out the >forward >> and backward propagation bits into distinct passes. > >They are already mostly split (2 separate loops in >ssa_forward_propagate_and_combine), so that wouldn't be hard. > >> The backward propagation >> bits are just a tree combiner and the idioms used to follow the >backward >> chains to create more complex trees and fold them need to be reusable > >> components. It's totally silly (and ultimately unmaintainable) that >each >> transformation is open-coding the walking of the use-def chain and >> simplification step.
Yeah - ideally the pattern matching would be abstract enough that it works on trees, gimple and rtl ... Using a domain specific language like Haskell would get you pattern combining for free. But I suppose with c++ you can come close enough to at least support tree and gimple ssa. >It isn't completely open-coded. get_prop_source_stmt, >can_propagate_from, >defcodefor_name, etc make walking the use-def chain not so bad. > >Usually at this point Richard refers to Andrew's work on a gimple >combiner... That or the gimple folding interface. Note the idea behind both should be to make the combined accessible from random passes just like we use fold_build now. Richard.
