llvm dev - Jul 2017 - failing to optimize boolean ops on cmps

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20170715/3494ba77/attachment.html>

Which is, of course, precisely why I didn't suggest that, it was Hal's
straw man.

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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20170715/d37e6b82/attachment.html>

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 <mailto: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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20170715/909956b7/attachment.html>