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: Marc Glisse <marc dot glisse at inria dot fr>,Jeff Law <law at redhat dot com>
- Cc: gcc-patches at gcc dot gnu dot org,Kai Tietz <ktietz at redhat dot com>
- Date: Sun, 21 Jul 2013 17:27:34 +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> <alpine dot DEB dot 2 dot 10 dot 1307191608181 dot 9828 at laptop-mg dot saclay dot inria dot fr>
Marc Glisse <firstname.lastname@example.org> wrote:
>On Fri, 19 Jul 2013, Jeff Law wrote:
>> It's also worth noting that fold-const.c also does some type
>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
>>>>> statements in reverse order, since this is the way the casts are
>>>>> propagated (would forwprop also work, just more slowly, or would
>>>>> opportunities across basic blocks?).
>>>> It would miss some opportunities,
>>> Could you explain in what case? I guess my trouble understanding
>>> 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
>> 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
>> situation occur regularly when I was looking at Kai's
>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
>> Now I believe one of Kai's goals is to allow our various pattern
>> folders to work better by not having to account for casting
>> often in sequences of statements we want to fold.
>Ah. I thought it was mostly so operations would be performed in a
>hopefully cheaper mode. Simplifying combiner patterns would be nice if
>>>> That's a real good question; I find myself looking a lot at the
>>>> 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
>>>> become evident as I continue to work through various improvements.
>>> It looks to me like a gimple version of fold, except that since it
>>> 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
>> everything as we convert from fold and to gimple_fold (or whatever we
>> it) is going to result in a horrid mess.
>> I find myself thinking that at a high level we need to split out the
>> 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
>> chains to create more complex trees and fold them need to be reusable
>> components. It's totally silly (and ultimately unmaintainable) that
>> 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,
>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
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.