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

[Sanjay Patel via llvm-dev]

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/b70dafa1/attachment.html>