On 07/12/2013 01:13 PM, Marc Glisse wrote:
Initial patch (from last year) actual implemented that in forwprop.
Ah, reading the conversation from last year helped me understand a bit
better.
It's also worth noting that fold-const.c also does some type
hoisting/sinking. Ideally that code should just be going away.
So by implementing type-demotion there too, would lead to
raise-condition. So there would be required additionally that within
forwprop a straight line-depth conversion is done for
statement-lists. All this doesn't fit pretty well into current
concept of forward-propagation ... The cast demotion is of course
something of interest for folding and might be fitting into
forward-propagation-pass too. The main cause why it is implemented
within demotion pass is, that this pass introduces such
cast-demotion-folding opportunities due its "unsigned"-type expansion.
So we want to fold that within pass and not waiting until a later pass
optimizes such redundant sequences away.
I hope we can at least find a way to share code between the passes.
Well, I'd like to pull all of the type hoisting/sinking code out to its
own pass. That may be a bit idealistic, but that's my hope/goal.
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.
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. I suspect that to
see benefit from that we'd have to hoist, fold, sink, fold. That argues
that hoisting/sinking should be independent of the folding step (which
shouldn't be a surprise to any of us).
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. 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.
Jeff
