This is an archive of the discontinued LLVM Phabricator instance.

[InstCombine] Re-enable guard canonicalization for AND and NOT OR
AbandonedPublic

Authored by mkazantsev on Jan 27 2017, 3:24 AM.

Details

Reviewers
sanjoy
apilipenko
Summary

The following changes:

r293061: "[InstCombine] Canonicalize guards for NOT OR condition"
r293058: "[InstCombine] Canonicalize guards for AND condition"

were reverted by the change

rL293227: "Revert a couple of InstCombine/Guard checkins"

because they contained a bug related to handling guards with multiple
arguments. The problem was that the extra arguments of the initial
guard were not passed to the newly-created guards.

This patch re-enables canonicalization of guards for AND and NOT OR
conditions and adds proper tests for them.

Diff Detail

Event Timeline

mkazantsev created this revision.Jan 27 2017, 3:24 AM
mkazantsev updated this revision to Diff 86040.Jan 27 2017, 3:33 AM
apilipenko added inline comments.Jan 31 2017, 12:41 AM
lib/Transforms/InstCombine/InstCombineCalls.cpp
3272–3279
SmallVector<Value *, 4> Args(CI->arg_begin(), CI->arg_end());
Args[0] = A;

And the same below.

mkazantsev updated this revision to Diff 86393.Jan 31 2017, 1:09 AM
mkazantsev marked an inline comment as done.
sanjoy requested changes to this revision.Jan 31 2017, 1:15 AM

As I said in the commit thread for rL293058, I don't think this is the right direction.

  • This is almost the opposite of widening; running this after widening will undo widening.
  • This increases the number of uses of deopt values, which will disable other instcombine transforms.
  • I suspect we'll have to pull some heroics to not regress code size. This is addressable with some effort, but I'd rather spend that effort on improving passes that fall over today on guard(X & Y).

I think the canonical form be a maximally widened guard, and not the converse. I would instead look at passes that seem deficient in terms of analyzing widened guards, and fix them.

This revision now requires changes to proceed.Jan 31 2017, 1:15 AM

I will prepare a couple of follow-up patches that widen the canonicalized guards after all transformations to avoid increase of code size due to this canonicalization.

mkazantsev abandoned this revision.Jan 31 2017, 10:26 PM