Hi Jeff, > We'd have to go back and find the PR. I don't remember all the > details, but the problem was big enough to make ASSERT_EXPRs a > far inferior solution to the others I'd looked at for recording > context sensitive equivalences.
Yes, inserting a bunch of ASSERT_EXPRs, updating SSA, running VRP, etc, all take a lot of time although using the information gathered by VRP for jump threading purposes is pretty straightforward and fast. So I am sandwiched between two things. 1) DOM is fairly fast with its iteration is limited, which shouldn't be too restrictive if we are running CCP/copy-prop before DOM. But DOM rebuilds information built by other passes, like keeping track of nonzero-ness, const/copy table, available expr table, etc. 2) VRP is slow and even slower with PHI node insertion. But if we use its result for jump threading, we are not duplicating much code. Plus the context-sensitive equivalences are globally visible and fine grained, so we don't have to mix identification of jump threading opportunities into a dom walk. (ASSERT_EXPRs and PHI nodes essentially splits a single variable into multiple variables, making a bunch of smaller live ranges to allow fine-grained value ranges to be stored.) Having said all this, I can't think of uses of these fine-grained context-sensitive equivalences other than jump threading, so I can't justify constructing this much information just for jump threading. > > > And, yes, it is imperative that we const/copy propagate into > > > ASSERT_EXPRs to the fullest extent possible. Otherwise we lose a lot > > > of threading opportunities. > > > > > ASSERT_EXPRs are regular expressions, so this is not a problem. > It is if you don't run const/copy propagation immediately after > insertion of the ASSERT_EXPRs :-) It may also be a problem to not run const/copy prop before insert ASSERT_EXPRs as noted in the problem of > D.18001_101 = D.18001_198; > D.18011_102 = D.18001_101->head_; > D.18001_12 = ASSERT_EXPR <D.18001_101, D.18001_101 != 0B>; where we are asserting a copy of D.18001_198, and D.18001_198 itself may also be used later. Kazu Hirata
