[llvm-commits] More aggressive speculation in SimplifyCFG

[Chandler Carruth]

On Fri, Jan 25, 2013 at 12:32 AM, Andrew Trick <atrick at apple.com> wrote:

> On Jan 24, 2013, at 5:19 PM, Chandler Carruth <chandlerc at google.com>
> wrote:
>
> On Thu, Jan 24, 2013 at 4:31 PM, Hal Finkel <hfinkel at anl.gov> wrote:
>
>> Chandler,
>>
>> Does your recent SimplifyCFG work affect this proposal?
>>
>
> Only a tiny bit.
>
> My work was to remove some hard-coded assumptions, and manually rolled
> cost models into thresholds and the TTI-based cost model. This shouldn't
> significantly change how the code is SimplifyCFG works or the tradeoffs
> LLVM makes. It continues to rely on something like early if-conversion for
> forming anything but trivial predicated formations.
>
> It should do two things (modulo bugs of course):
> 1) It makes the existing "if-conversion"-like functionality in SimplifyCFG
> both more correct and consistent. It will no longer fail to convert equally
> trivial constructs, and it will no longer mistakenly convert expensive
> constructs.
>
> 2) It makes the mechanism for the transformation itself a bit more
> flexible and robust, so that *if* we ever have a reason to do more of this
> in the IR, the code can actually handle it.
>
>
> I still thing it is worth investigating the pattern I described, and I
> think Dan is thinking about some of these issues.... But there are still
> some hard problems to solve to make it feasible & profitable. =]
>
>
> Most of the code changes to improve metrics/heuristics so far look great...
>

Awesome. Yell if that changes, but the what I've been poking at thus far,
I'm really trying to stay on the extreme end of conservative and
non-controversial.


> but to address your future plans for TTI and respond to the patch that
> started this thread:
>

I don't actually have a plan. I had an idea. I've also talked about it with
Dan, and I think he was going to think more and look into whether it
actually works, if so how, and write it up. We'll see.

Anyways, to the more general comments here:


> Early passes, like SimplifyCFG, whose job is to canonicalize IR should try
> to avoid using heuristics driven by thresholds. No disagreement I'm sure.
> But along the same lines, when we do need heuristics to avoid IR bloat,
> they should be derived purely from the IR, not TTI. This applies to any
> pass that we would like to run before we start lowering. i.e. before the
> late IR loop optimizations (loop-idiom, vectorize, partial unroll). This
> way, the IR doesn't deviate much across targets until we start running
> passes that actually care about the target. If I'm writing an optimization
> that I think is target-independent, I'd like it to work the same way across
> targets without worrying about seemingly random changes to the IR. I've
> wasted plenty of time debugging issues in LSR that are affected in
> unpredictable ways by target info. That problem will be greatly magnified
> as we start moving TTI earlier.
>
> Regardless, we need a way of checking whether certain intrinsics are
> always free, independent of TTI. And with that, I'm guessing a purely
> IR-based heuristic work nearly as well as one based on TTI. If the actual
> mechanism to achieve this is to simply force NoTTI for "early" passes,
> that's fine--but does seem decepetive.
>
> You may disagree with me on inlining. I concede that we might make some
> exceptions, but the exceptions should be justifiable based on experience.
>

At a high level, I'm a bit torn here. There are lots of places where I
agree, but also quite a few where I disagree... But I don't think in any
way that impacts this patch, SimplifyCFG, or other stuff going on right now.

I think this is really just part of a longer discussion about how target
information should and shouldn't be used within IR passes, and how to
structure things, and we'll have a hard time even discussing the issues in
the context of this thread. =] Certainly, I think every interesting example
I come up with has *nothing* to do with this thread.

At some point, I'd like to find a time when we can sit down and really dig
into this and come up with a good model, but hopefully there is no real
urgency here... At least, I don't expect either fast or radical changes
w.r.t. much of these pieces of the optimizer.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20130125/7c39ef0a/attachment.html>