[llvm] r303387 - [InstCombine] add more tests for xor-of-icmps; NFC

[Sanjay Patel via llvm-commits]

Is "VRP" (value range propagation) in LLVM-speak "CVP" (correlated value
propagation)?

If so, we have this comment regarding compares:
  // As a policy choice, we choose not to waste compile time on anything
where
  // the comparison is testing local values.

Or this for div/rem:
  // As a policy choice, we choose not
  // to waste compile time on anything where the operands are local defs.

"Local" means in the same basic block from what I can tell by the code
here.

I think this means that this pass explicitly defers handling simple cases
like:
https://reviews.llvm.org/D33342
...to another pass, and currently that pass is InstCombine (because the
patterns really can't be any simpler than the tests in that patch, right?).

I think that improving compile-time should not preclude improving
InstCombine. We should do both.


On Thu, May 18, 2017 at 5:25 PM, Davide Italiano <davide at freebsd.org> wrote:

> On Thu, May 18, 2017 at 4:20 PM, Sanjay Patel <spatel at rotateright.com>
> wrote:
> > No, I haven't looked at VRP yet, so I don't know why it's not handled
> there.
> > I was assuming that since InstSimplify/InstCombine already have a large
> > chunk of folds for the and/or variants, it would make sense to also
> handle
> > xor there.
> >
>
> It depends. I think InstCombine should always try to get the
> "easy/cheap" cases (and in general make local decisions) and then
> leave more complex transformations to other passes. I think auditing
> what's good and what's not to do in InstCombine will be a major
> undertaken in LLVM, but at some point we should just bite the bullet
> and do it :) (side effect, reduced number of matchers would improve
> compile time).
>
> > I have a patch in progress that would handle these cases using the
> existing
> > code (truth tables!). Let me post that for review and see what you think
> > about it.
> >
>
> Thanks. Feel free to always post mock-ups for review.
>
> --
> Davide
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20170519/fbbda001/attachment.html>