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

[Sanjay Patel via llvm-dev]

For the record, Craig found a better way to solve the immediate problem
than what I had thought of:
https://reviews.llvm.org/D35451

So for this brief moment, instcombine should get both more powerful and
slightly more efficient. I agree with the position that this just delays
the inevitable day when we need to break instcombine up by giving it more
defined goals. Some people would say we already hit that point, and I
believe it...but I've asked multiple times for a bug report, test case, or
profile with no reply. Hacking at it would again just be delaying a
structural change, but I think it's still worth looking at.


On Sat, Jul 15, 2017 at 2:20 PM, Philip Reames via llvm-dev <
llvm-dev at lists.llvm.org> wrote:

> On 07/15/2017 01:09 PM, Daniel Berlin wrote:
>
> Which is, of course, precisely why I didn't suggest that, it was Hal's
> straw man.
>
> Ah, sorry for the misread then.  Skimming the thread, that's exactly what
> I thought you *were* arguing for.  Glad to know we're in agreement.
>
>
> On Sat, Jul 15, 2017, 12:26 PM Philip Reames <listmail at philipreames.com>
> wrote:
>
>> On 07/14/2017 11:46 AM, Hal Finkel via llvm-dev 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.
>>
>> Just want to chime in here in support of what Hal said.  I strongly
>> believe we should not block incremental progress unless we have a plan in
>> place for a better design.  In particular, part of being able to come up
>> with a better design is having multiple people with recent knowledge of the
>> system which needs replaced and stopping evolution of the old system by
>> definition inhibits having such a group of people.
>>
>> Philip
>>
>
>
> _______________________________________________
> 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/20170715/3e7687e9/attachment.html>