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
