[Bug tree-optimization/25243] [4.1/4.2 Regression] Jump threading opportunity missed in tree-ssa but caught in jump1

2006-02-10 Thread steven at gcc dot gnu dot org 


--- Comment #9 from steven at gcc dot gnu dot org  2006-02-11 00:48 ---
Fixed with the 2nd VRP pass Jeff added recently:

2006-02-07  Jeff Law  law at redhat dot com

* tree-vrp.c (find_conditional_asserts): Update comments.
(simplify_stmt_for_jump_threading): New.
(etc.)


-- 

steven at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25243

[Bug tree-optimization/25243] [4.1/4.2 Regression] Jump threading opportunity missed in tree-ssa but caught in jump1

2005-12-05 Thread steven at gcc dot gnu dot org 


--- Comment #7 from steven at gcc dot gnu dot org  2005-12-05 18:05 ---
Created an attachment (id=10410)
 -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10410action=view)
follow SSA_NAME_VALUE deep

Hmmwell, the attached patch does bootstrap on i686,ia64, and x86-64, and it
passes regression testing on those targets too.  Jeff, do you have an example
of when this could go into an infinite loop?


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25243

[Bug tree-optimization/25243] [4.1/4.2 Regression] Jump threading opportunity missed in tree-ssa but caught in jump1

2005-12-05 Thread law at redhat dot com 


--- Comment #8 from law at redhat dot com  2005-12-05 18:18 ---
Subject: Re:  [4.1/4.2 Regression] Jump
threading opportunity missed in tree-ssa but caught in jump1

On Mon, 2005-12-05 at 18:05 +, steven at gcc dot gnu dot org wrote:
 
 --- Comment #7 from steven at gcc dot gnu dot org  2005-12-05 18:05 
 ---
 Created an attachment (id=10410)
 -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10410action=view)
  -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10410action=view)
 follow SSA_NAME_VALUE deep
 
 Hmmwell, the attached patch does bootstrap on i686,ia64, and x86-64, and it
 passes regression testing on those targets too.  Jeff, do you have an example
 of when this could go into an infinite loop?
Try putting it in lookup_avail_expr.  ie, instead of following one chain
back, make it a loop.

I'd also really rather look at moving away from the equivalency chains,
which would also address this problem.  What's preventing that is things
actually get slower when we fully propagate constants/copies as they are
discovered.

jeff


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25243

[Bug tree-optimization/25243] [4.1/4.2 Regression] Jump threading opportunity missed in tree-ssa but caught in jump1

2005-12-03 Thread pinskia at gcc dot gnu dot org 


--- Comment #4 from pinskia at gcc dot gnu dot org  2005-12-03 17:01 ---
This looks very much related to PR 21829.

Hmm, in 4.0.0 we got Before DOM (likewise for 4.1.0 and above):
L1:;
  i_2 = i_10 + 1;
  if (i_2 != 4) goto L0; else goto L3;

  # i_7 = PHI i_2(2);
L3:;
  if (i_7 == 4) goto L4; else goto L5;

but after:
L1:;
  i_2 = i_10 + 1;
  if (i_2 != 4) goto L0; else goto L3;

Invalid sum of incoming frequencies 2375, should be 0
  # i_7 = PHI i_2(2);
L3:;
  foo (r_3);

Which means that GCC got it right in 4.0.0


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

  BugsThisDependsOn||21829
  Known to fail||4.1.0 4.2.0
  Known to work||4.0.0 4.0.2
Summary|Jump threading opportunity  |[4.1/4.2 Regression] Jump
   |missed in tree-ssa but  |threading opportunity missed
   |caught in jump1 |in tree-ssa but caught in
   ||jump1
   Target Milestone|--- |4.2.0


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25243

[Bug tree-optimization/25243] [4.1/4.2 Regression] Jump threading opportunity missed in tree-ssa but caught in jump1

2005-12-03 Thread steven at gcc dot gnu dot org 


--- Comment #5 from steven at gcc dot gnu dot org  2005-12-03 17:46 ---
Actually, it's more related to Bug 21488.  What happens is that we record a
value for the left hand side of a single-argument PHI node (i.e. for
rhs=PHI(lhs) we record an equivalence rhs==lhs), but the left hand side also
already has a value (in this case, lhs==4).

Later on we don't copy propagate lhs into the uses of rhs because lhs is
defined in a loop and we don't copy propagate out of loops, so we never see
that rhs==4 too.

My hack in comment #3 propagates the value 4 by following SSA_NAME_VALUE
links as deeply as possible.  What we should probably do instead is look
through SSA_NAME_VALUE chains in record_equivalences_from_phis.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25243

[Bug tree-optimization/25243] [4.1/4.2 Regression] Jump threading opportunity missed in tree-ssa but caught in jump1

2005-12-03 Thread law at redhat dot com 


--- Comment #6 from law at redhat dot com  2005-12-03 18:27 ---
Subject: Re:  [4.1/4.2 Regression] Jump
threading opportunity missed in tree-ssa but caught in jump1

On Sat, 2005-12-03 at 17:46 +, steven at gcc dot gnu dot org wrote:
 
 --- Comment #5 from steven at gcc dot gnu dot org  2005-12-03 17:46 
 ---
 Actually, it's more related to Bug 21488.  What happens is that we record a
 value for the left hand side of a single-argument PHI node (i.e. for
 rhs=PHI(lhs) we record an equivalence rhs==lhs), but the left hand side also
 already has a value (in this case, lhs==4).
 
 Later on we don't copy propagate lhs into the uses of rhs because lhs is
 defined in a loop and we don't copy propagate out of loops, so we never see
 that rhs==4 too.
 
 My hack in comment #3 propagates the value 4 by following SSA_NAME_VALUE
 links as deeply as possible.  What we should probably do instead is look
 through SSA_NAME_VALUE chains in record_equivalences_from_phis.
The reason we don't generally walk through those chains is it is
possible to get loops in the value chain.  I've always considered
this a semi-bug in DOM.

Jeff


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25243