[llvm-dev] failing to optimize boolean ops on cmps

[Craig Topper via llvm-dev]

Reassociate very explicitly doesn't handle i1 at all. But even if it did,
the processing for OR doesn't look at its arguments other than finding
duplicates and direct inverses. But it won't look through the and to find
an inverse.

~Craig

On Fri, Jul 14, 2017 at 2:03 PM, Sanjay Patel <spatel at rotateright.com>
wrote:

> That's a good point. The factorization / reassociation in instcombine is
> just too limited I think. This raises another pair of questions though:
>
> 1. Why doesn't -reassociate catch this either?
> 2. And if we teach reassociate to match this, can we remove some redundant
> functionality from instcombine?
>
> On Fri, Jul 14, 2017 at 12:54 PM, Craig Topper via llvm-dev <
> llvm-dev at lists.llvm.org> wrote:
>
>> Going back to the original problem. Why shouldn't
>> SimplifyUsingDistributiveLaws handle both these cases?
>>
>> For the bitwise test case if you distribute you get
>> (~A | A) & (B | A)
>>
>> The left side of that simplifies to all 1s which is the identify value
>> for and. So even though the right side doesn't simplify it's a win.
>>
>> ~Craig
>>
>> On Fri, Jul 14, 2017 at 11:46 AM, Hal Finkel via llvm-dev <
>> llvm-dev at lists.llvm.org> wrote:
>>
>>>
>>> On 07/14/2017 01:38 PM, Daniel Berlin wrote:
>>>
>>>
>>>> Not sure about this last part. It is really going to require work by us
>>>> to rewrite things. :-) In the mean time, I think we should go ahead with
>>>> this.
>>>>
>>>
>>> FWIW: My problem is, when put in this framework, we will repeatedly make
>>> this same decision, this same way, again and again, and never actually get
>>> even started on fixing it :)
>>>
>>> IE "it's just another small patch!"
>>>
>>>
>>> You're correct. However, as I'm sure you're aware, developer time is not
>>> directly transferable in a way that makes any other decision optimal. It's
>>> not like blocking all improvements to InstCombine will cause a movement to
>>> appear to rewrite InstCombine. It will only cause a shrink in the pool of
>>> developers with recent experience working on InstCombine (and a lot of
>>> out-of-tree patches). Frankly, we don't even have a concrete plan for how
>>> we'd do this, or even a target design, and that's the first item on the
>>> critical path to a rewrite. We should start an RFC and iterate on this
>>> until we have a concrete plan and migration plan.
>>>
>>>  -Hal
>>>
>>> --
>>> Hal Finkel
>>> Lead, Compiler Technology and Programming Languages
>>> Leadership Computing Facility
>>> Argonne National Laboratory
>>>
>>>
>>> _______________________________________________
>>> LLVM Developers mailing list
>>> llvm-dev at lists.llvm.org
>>> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>>>
>>>
>>
>> _______________________________________________
>> LLVM Developers mailing list
>> llvm-dev at lists.llvm.org
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20170714/dd2a9981/attachment.html>