This is the mail archive of the
mailing list for the GCC project.
Re: RFC: Add of type-demotion pass
- From: Marc Glisse <marc dot glisse at inria dot fr>
- To: Jeff Law <law at redhat dot com>
- Cc: gcc-patches at gcc dot gnu dot org, Kai Tietz <ktietz at redhat dot com>
- Date: Fri, 19 Jul 2013 17:55:27 +0200 (CEST)
- Subject: Re: RFC: Add of type-demotion pass
- References: <155227895 dot 847667 dot 1373305519786 dot JavaMail dot root at redhat dot com> <alpine dot DEB dot 2 dot 10 dot 1307082119400 dot 3917 at laptop-mg dot saclay dot inria dot fr> <51DC91B6 dot 4070409 at redhat dot com> <alpine dot DEB dot 2 dot 10 dot 1307121944320 dot 7127 at stedding dot saclay dot inria dot fr> <51E939C4 dot 3060407 at redhat dot com>
On Fri, 19 Jul 2013, Jeff Law wrote:
It's also worth noting that fold-const.c also does some type
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.
Anytime you hoist/sink a cast, you're moving it across an operation -- which
can expose it as a redundant cast.
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...
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
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 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
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.
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.
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
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