<div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Nov 4, 2014 at 2:03 PM, Mark Heffernan <span dir="ltr"><<a href="mailto:meheff@google.com" target="_blank">meheff@google.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">It seems to me that LoopSimplify is the problem here.</blockquote><div><br></div><div>Yes.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> Should LoopSimplifyPass be marked as IsCFGOnlyPass?  It clearly modifies the CFG.  From the "writing an llvm pass" manual:  "if a pass walks CFG without modifying it then the third argument [isCFGOnly] is set to true", however, I don't know how definitive that is and the logic of that statement doesn't exactly imply that a CFG-modifying pass can't be marked isCFGOnly.  If LoopSimplifyPass is changed to !isCFGOnly, then preservesCFG can be added back to instcombine (at least for the purposes of the bug I ran into).</blockquote><div><br></div><div>This seems like the correct fix to me. I strongly disagree with the original approach (although I understand how you got there).</div><div><br></div><div>There is absolutely no reason why preserving the CFG should be equivalent to preserving LoopSimplify.</div><div><br></div><div>In fact, preserving LoopSimplify never *really* makes sense because it is a transformation pass, not an analysis pass. But in the current pass manager we have no effective alternative. =[ <br></div></div><br><br></div></div>