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

[Hal Finkel via llvm-dev]

On 07/14/2017 02:04 PM, Daniel Berlin wrote:
>
>
> On Fri, Jul 14, 2017 at 11:46 AM, Hal Finkel <hfinkel at anl.gov 
> <mailto: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.

Correct, we should insist on the best technical decisions given the 
current infrastructure (or current infrastructure with incremental 
improvements).

>
>     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.

No offense taken, but at this point, even if we were going to push 
people to work on a new system, we don't even have a concrete thing to 
suggest they do. I'd be really interested in exploring, for example, 
whether some Stratego/XT-like system would be better, and how we might 
construct it, the degree to which such a system can remain sound and 
efficient in the presence "arbitrary" C++ predicates, etc. There's also 
significant interest in encoding these transformations in a form that 
can be mechanically transformed such that they can be verified by some 
SMT-solver-backed checker (e.g. Alive).

Thanks again,
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/d918cb85/attachment.html>