This is the mail archive of the 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 <> 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
>>>>> statements in reverse order, since this is the way the casts are
>>>>> 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
>> 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
>> situation occur regularly when I was looking at Kai's
>> 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
>> 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
>operations as 
>> 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 worked.
>>>> 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.


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