[PATCH] InstCombine ((x | ~y) ^ (~x ^ y)) to (x & ~y)

[Peter Collingbourne]

On Thu, Aug 28, 2014 at 09:28:54AM -0700, Daniel Berlin wrote:
> On Thu, Aug 28, 2014 at 8:05 AM, Anton Korobeynikov <anton at korobeynikov.info
> > wrote:
> 
> > > There is a discussion is going on at
> > http://lists.cs.uiuc.edu/pipermail/llvmdev/2014-August/075532.html
> > regarding a more general way to handle matching
> > > different patterns. If we can come up with a general approach that would
> > be best. But till then we should not miss any optimizing opportunity I
> > think.
> >
> 
> I'm confused.  Is there an urgent reason not to slow down and think about
> this?
> 
> Sure. Just present how often this pattern triggers on LLVM testsuite and
> > SPEC.
> >
> > As Anton implies, everything is tradeoffs.
> 
> Adding a *ton* of separate matchers (and so far i've seen a *lot* go by
> here) without any data that they ever trigger on anything, or make any
> difference, is likely to add maintenance burden/etc for little benefit.
> 
> LLVM *already* misses optimizing opportunities everywhere, *on purpose*,
> because the cost of getting those optimizing opportunities, in terms of
> both compile time and code maintenance, is greater than the benefit to the
> program runtime.
> 
> I don't see why this area of the compiler would be subject to different
> rules.
> 
> So, like Anton, i'd really like to see data here, or a real design, as the
> amount of stuff being added is getting quite large.

The Souper project [1] has an LLVM pass that uses an SMT solver to apply
these types of transformations automatically. In this context, it could be
useful for giving a ~upper bound on the potential performance benefits
for optimizations such as this one.

We've recently been thinking about extending the pass to get data on the
performance benefits of each individual transformation it applies by adding
profiling instrumentation to the transformed IR.

Thanks,
-- 
Peter

[1] https://github.com/google/souper