[llvm-dev] failing to optimize boolean ops on cmps
Hal Finkel via llvm-dev
llvm-dev at lists.llvm.org
Fri Jul 14 12:16:52 PDT 2017
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
> 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).
Lead, Compiler Technology and Programming Languages
Leadership Computing Facility
Argonne National Laboratory
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the llvm-dev