[llvm-commits] More aggressive speculation in SimplifyCFG

[Andrew Trick]

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... but to address your future plans for TTI and respond to the patch that started this thread:

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.

Another example is LoopRotate which I'm sure will work just as well using IR-based heuristics.

Now for SimplifyCFG. Since it only if-converts to expose InstCombine pattern, its heuristics should clearly be based on IR, not TTI.

Some targets may want to do aggressive select formation before ISEL, but that is not a reason to turn SimplifyCFG into MangleCFG. These targets should run an IR-level CFG flattening pass, but only under the following conditions:

1) It's only done as a "lowering" pass, after the standard optimization/loop passes and after the last SimplifyCFG pass.
2) It's only done for the purpose of exposing important ISEL opportunities.
3) We provide a reverse if-conversion pass to undo Flattening's innevitable mistakes, which doesn't exist to my knowledge.

As Evan and Jakob said, the machine code EarlyIfConverter knows all about latencies and critical paths, which is essential for profitable if-converstion. If target's want aggressive pre-ISEL if-conversion, then we need to add reverse if-conversion here.

-Andy

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20130125/45887656/attachment.html>