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

[John Regehr]

We can make finding instances of this transformation (and ones like it) a 
short-term goal, with results within ~1 month.

John


On 08/28/2014 12:31 PM, Peter Collingbourne wrote:
> 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,
>