This is the mail archive of the gcc-bugs@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[Bug tree-optimization/42108] [4.4/4.5 Regression] 50% performance regression



------- Comment #35 from matz at gcc dot gnu dot org  2009-12-14 16:58 -------
Exactly my thinking (growing SCCs -> slow, sorting SCCs -> difficult).
What I thought about the trapping problem is that in this situation we could
ignore the trap test.  We start with this situation:

bb1:
  goto bb2
bb2:
  PHI<from bb1, from bbX>     ; with bbX being dominated by bb1
  a = b / c                   ; with b and c loop invariant

Now it's clear that inserting a computation b/c in bb1 does not ever introduce
additional traps, as there's no intervening statement that could stop
execution without us knowing (in PR38819 it's a call that does exit(0)).


-- 


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]