This is the mail archive of the
mailing list for the GCC project.
Re: RFC: Add of type-demotion pass
- From: Richard Biener <richard dot guenther at gmail dot com>
- To: Jeff Law <law at redhat dot com>,gcc-patches at gcc dot gnu dot org
- Cc: Marc Glisse <marc dot glisse at inria dot fr>,Kai Tietz <ktietz at redhat dot com>
- Date: Fri, 19 Jul 2013 17:41:36 +0200
- Subject: Re: RFC: Add of type-demotion pass
- References: <155227895 dot 847667 dot 1373305519786 dot JavaMail dot root at redhat dot com> <alpine dot DEB dot 2 dot 10 dot 1307082119400 dot 3917 at laptop-mg dot saclay dot inria dot fr> <51DC91B6 dot 4070409 at redhat dot com> <alpine dot DEB dot 2 dot 10 dot 1307121944320 dot 7127 at stedding dot saclay dot inria dot fr> <51E939C4 dot 3060407 at redhat dot com>
Jeff Law <email@example.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
>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
>>> 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
>>> So we want to fold that within pass and not waiting until a later
>>> 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
>>>> statements in reverse order, since this is the way the casts are
>>>> propagated (would forwprop also work, just more slowly, or would it
>>>> opportunities across basic blocks?).
>>> It would miss some opportunities,
>> Could you explain in what case? I guess my trouble understanding this
>> the same as in the next question, and I am missing a fundamental
>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
>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
>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.
>> I don't really see why that would make it an unmaintainable mess,
>> 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
>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 ...