This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: RFC: Add of type-demotion pass


Marc Glisse <marc.glisse@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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]