Daniel Berlin via llvm-dev
2017-Jul-14 18:38 UTC
[llvm-dev] failing to optimize boolean ops on cmps
> > > 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!" -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20170714/8ae964ac/attachment.html>
Daniel Berlin via llvm-dev
2017-Jul-14 18:38 UTC
[llvm-dev] failing to optimize boolean ops on cmps
But i'm also fine if we go ahead because i'm not offering to do the work :) On Fri, Jul 14, 2017 at 11:38 AM, Daniel Berlin <dberlin at dberlin.org> 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!" > >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20170714/a460ce44/attachment.html>
Hal Finkel via llvm-dev
2017-Jul-14 18:46 UTC
[llvm-dev] failing to optimize boolean ops on cmps
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 -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20170714/a4dac3d6/attachment-0001.html>
Craig Topper via llvm-dev
2017-Jul-14 18:54 UTC
[llvm-dev] failing to optimize boolean ops on cmps
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 > >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20170714/82de9201/attachment.html>
Daniel Berlin via llvm-dev
2017-Jul-14 19:04 UTC
[llvm-dev] failing to optimize boolean ops on cmps
On Fri, Jul 14, 2017 at 11:46 AM, Hal Finkel <hfinkel at anl.gov> 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. >Of course not, but this sets it up as an all or nothing thing, and it's not. Though you probably will need a stop loss point in the future.> 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). >This is not the only effect it will have, and i don't believe you think that either (since this argument is globally applicable to the degree that it would mean we should just accept *every patch* rather than push people to better design stuff). It would also, for example, push people towards putting transformations elsewhere.> 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. >Sure, and frankly, you will never get one until either someone decides to be super-altruistic, or you start pushing on people a little more than "not at all". We should start an RFC and iterate on this until we have a concrete plan> and migration plan. >I don't believe that will actually achieve anything at this point (really, no offense meant) So I'm just going to leave this stuff alone since it's pretty clear people just view me as being either obstructionist or unrealistic. I don't see anything happening until we are willing to push more, and i don't see that happening until instcombine is even worse than it is now. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20170714/d26b4c96/attachment.html>
Philip Reames via llvm-dev
2017-Jul-15 19:26 UTC
[llvm-dev] 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>