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


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.

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...

--
Marc Glisse


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