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

[Peter Collingbourne]

On Thu, Aug 28, 2014 at 11:25:57AM -0700, Peter Collingbourne wrote:
> 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.

I think I oversold it a little. It wouldn't be able to automatically apply
this specific transformation. At the moment it can simplify boolean expressions
to constant 0 or 1. But we've been thinking about simplifying wider constants
as well.

Thanks,
-- 
Peter