http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47271
Jakub Jelinek <jakub at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |jakub at gcc dot gnu.org
--- Comment #7 from Jakub Jelinek <jakub at gcc dot gnu.org> 2011-01-24
18:02:45 UTC ---
Not sure if it actually was so good idea to remove the edge conditions.
If the bb_predicate (first_edge->src) and bb_predicate (second_edge->src) are
negations of each other, then it is easy, similarly if one of the
first_edge->src
and second_edge->src bbs dominates the other one.
But if neither of those two bbs dominates the other one, then either we have
the edge conditions and can use condition bb_predicate (bb) together with one
(or the other) edge conditions, or we'd need to reconstruct both conditions (we
have them gimplified) and xor them together to see the actual difference in
between those and see in which one of the two conditions is the delta
contained.
How much memory savings did
http://gcc.gnu.org/ml/gcc-patches/2010-05/msg02294.html
actually bring in?
Perhaps we wouldn't have to store the whole conditions into edge aux fields,
but instead just a boolean that would help find_phi_replacement_condition
choose which of the two conditions to use (or it could be stored as two bits in
the target bb's bb_predicate* structure). All I wanted to say is that
especially with even far more complicated loops then this one reconstructing
which condition and bb to use in find_phi_replacement_condition is going to be
more difficult than finding it out earlier (during predicate_bbs most likely).
