<div dir="ltr">I forgot #4 :)<div><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div>I'm not sure how we want to paper over this bug:<br><br></div><div>1. Making first run of GVN not generate IR the second GVN will have to trivially simplify (which will fix some cases but not others)</div><div><br></div><div>2. Make BasicAA see through phi nodes (ditto, though chandler points out there are plenty of normal programs  with thousands of phi nodes that have the same arguments, and since basicaa does not cache, there is a compile time cost to doing this )</div><div><br></div><div>3. Add an API and use it to blow away memdep cache entirely between GVN iterations (which will fix all such cases at some possible compile time cost)</div><div><br></div></div></blockquote><div><br></div><div>4. Call simplifyInstruction in *every* path that BasicAA goes down. This will also fix it, and if you get every pass, might even fix all of them.</div><div><br></div><div>FWIW: I think we want to do the reverse.  Performing tons of constant folding in BasicAA, which is what happens now, seems ... broken, and is one of the many things that makes it slow if it hits certain types of instructions.</div><div><br></div><div>It seems like pretty much everything in the world is trying to simplify instructions further under the covers (getUnderlyingObject, etc).  We try to simplify and constant fold the same instruction 8 or 9 times during some basicaa calls right now!</div><div><br></div><div><br></div></div></div></div></div>