<div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Feb 13, 2015 at 11:52 AM, Michael Zolotukhin <span dir="ltr"><<a href="mailto:mzolotukhin@apple.com" target="_blank">mzolotukhin@apple.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div>Thank you for the work and pointing out to the problems! It’s good that we found them early.</div><div><br></div><div>I think that we would solve these issues if we do the following:</div><div>1. When looking for simplified instructions, visit each instruction only once. That’ll be achieved by visiting blocks in pre-order.</div><div>2. When looking for dead-instructions, also visit them only once - here we would need to visit blocks in reverse-order.</div><div>3. SCEV indeed might be too slow for this, but we actually only interested in expressions that become constants. That means, we need SCEV for expressions that either feed a load, or have constant Start and Step SCEV-expressions. We can scan all insns once and cache results for such potentially-constant instructions, other instructions don’t need SCEV-expression. So, we won’t need to talk to SCEV after this point.</div><div>4. As for using threshold for early-exit - that’s a really good idea, and it should integrate here naturally.</div><div><br></div><div>What do you think about this? Am I missing something, or does it sound right?</div></blockquote><div><br></div><div>Generally yes, but I would start without trying to handle dead instructions, and following the sketch of how to build it I gave. I would then layer dead instructions on as a follow-up. There are several different approaches to handling dead instructions, and I think it will be useful to see how things look without handling them first.<br></div><div><br></div><div>Note that the outline I gave naturally will skip dead *control flow*, because we can simplify the condition to a constant and only traverse one of the successors.</div></div></div></div>