<div dir="ltr"><div>InstCombine consists of iteration of the following two steps</div><div><br></div><div>1. Building the worklist over the function. Including dead code elimination, constant folding, and constant argument folding.</div><div>2. Processing the worklist.</div><div><br></div><div>InstCombine currently only reports a change to the pass manager if more than 1 iteration is executed. And we only do additional iterations when worklist processing changed something.</div><div><br></div><div>But the first iteration could do deadcode elmination or constant folding during the worklist build, but make no changes during the processing. Do those count as changes that should be passed up to the pass manager?</div><div><br></div><div>There's an additional odd quirk here, if we constant fold an argument during the worklist build we do return a changed flag from the worklist build which gets ORed with the change flag for the worklist processing. This can force another iteration even if the worklist processing itself doesn't make any change. I've seen this happen during some InstCombine runs where we constant fold a GEP ConstantExpr just to change an i32 to i64 for one of the indices.Clearly we shouldn't be forcing a subsequent iteration just because the worklist build changed something but the worklist itself didn't.</div><div><br></div><div>Thanks,</div><div><div class="gmail_signature" data-smartmail="gmail_signature">~Craig</div></div>
</div>