Re: RFC: Add of type-demotion pass

[Richard Biener <richard dot guenther at gmail dot com>]

Jeff Law <law@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