Jeff Law <l...@redhat.com> wrote: >On 07/12/2013 01:13 PM, Marc Glisse wrote: >>> Initial patch (from last year) actual implemented that in forwprop. >> >> Ah, reading the conversation from last year helped me understand a >bit >> better. >It's also worth noting that fold-const.c also does some type >hoisting/sinking. Ideally that code should just be going away. > > >>> So by implementing type-demotion there too, would lead to >>> raise-condition. So there would be required additionally that >within >>> forwprop a straight line-depth conversion is done for >>> statement-lists. All this doesn't fit pretty well into current >>> concept of forward-propagation ... The cast demotion is of course >>> something of interest for folding and might be fitting into >>> forward-propagation-pass too. The main cause why it is implemented >>> within demotion pass is, that this pass introduces such >>> cast-demotion-folding opportunities due its "unsigned"-type >expansion. >>> So we want to fold that within pass and not waiting until a later >pass >>> optimizes such redundant sequences away. >> >> I hope we can at least find a way to share code between the passes. >Well, I'd like to pull all of the type hoisting/sinking code out to its > >own pass. That may be a bit idealistic, but that's my hope/goal. > > >> >>>> 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. > >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. I suspect that to > >see benefit from that we'd have to hoist, fold, sink, fold. That >argues >that hoisting/sinking should be independent of the folding step (which >shouldn't be a surprise to any of us). > > >>> 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. 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.
Splitting forward and backward propagation into separate passes creates a pass ordering issue. Rather than that all forward propagations should be formulated as backward or the other way around. A bit awkward in some cases maybe, but you can at least drive forward propagations from their sinks. As of a type demotion pass - I'd rather have this kind of thing as a lowering exposing mode promotion somewhen late in the simple optimizing stage. Btw, other demotions still happen from convert.c ... Richard. >Jeff
