[llvm-dev] [InstCombine] When should InstCombine indicate something was changed to the pass managers?

Craig Topper via llvm-dev llvm-dev at lists.llvm.org
Tue Apr 4 12:56:38 PDT 2017


InstCombine consists of iteration of the following two steps

1. Building the worklist over the function. Including dead code
elimination, constant folding, and constant argument folding.
2. Processing the worklist.

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.

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?

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.

Thanks,
~Craig
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20170404/bb4a9887/attachment.html>


More information about the llvm-dev mailing list