Hi Diego, > By merging, do you mean *replacing* CCP with VRP? Yes, it's > doable. No, it's not a good idea.
Understood. Also, if we are inserting ASSERT_EXPRs, it seems to be a good idea to run copy-prop before VRP. Otherwise, we would end up with lots 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>; Note that ASSERT_EXPR is on D.18001_101, not on D.18001_198, which is older. As a result, VRP does not notice that D.18001_198 != 0B. Currently, we still have these even after copy prop because we don't allow copy propagation between const and non-const pointers, which I think is a bit too restrictive. > At one point, all the passes had to deal with ASSERT_EXPRs. > Mostly by ignoring them. Which is additional, unwanted work > because some of them had to actively know about them being > nothing but fancy copy operations. That gets in the way of their > work. I think that ASSERT_EXPRs should only survive as long as > they're useful. Yes, playing with VRP, I've realized that I am not interested in ASSERT_EXPRs per se, but I am more interested in SSA_NAME_VALUE_RANGE that VRP leaves us with. > Sure. Go ahead. My short term plan is to start merging the various > components into mainline. I'll start with the incremental SSA > patches, followed by VRP, the CCP and copy-prop improvements. > Perhaps we could leave the changes to the threader in TCB for a > little while longer, but first I need to read your proposal in > detail. Thank you. It turns out that if I blindly insert ASSERT_EXPRs for everything that allows us to infer a range, my jump threading pass finds more opportunities than what the current DOM can find. There are certain classes of opportunities that my pass misses but DOM catches, but I'll mention them in a separate message. > ISTR either stevenb or dberlin implementing a dom-order > propagation. I think they got a minor speedup that could be > worth having. Huh, whey I talked to them on IRC they didn't seem to have implemented this. I'll try to get this issue one of these days. Kazu Hirata
