------- 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
