On Wed, 2005-03-30 at 14:19 -0500, Kazu Hirata wrote: > 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. Right. This is the biggest thing I want to attack once I wrap up the threading changes and aliasing changes (and being stuck in Atlanta for 3 days due to the recent storms was certainly a step backwards in wrapping up the threading changes :(
I've got some ideas on how to avoid the iteration step currently inside DOM. I want to start playing with those to see if it actually makes sense. > > 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. Except that you need to know what expressions are currently available when you do jump threading. We currently get that information from the DOM walk. We might be able to avoid that in the future, but I don't think we can do that just yet. Jeff
