[llvm-commits] More aggressive speculation in SimplifyCFG

[Duncan Sands]

Hi Andrew,

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

+1

I'm worried that TTI use is going to spread all over the IR optimizers because
using it is tempting and easy, and not because people tried hard to do without
it but failed.  By failed I mean when real-world programs show a significant
improvement thanks to using target information, and it wasn't possible to get
an equivalent improvement using a clever pure IR solution + codegen.

Ciao, Duncan.

>
> 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
>
>
>
> _______________________________________________
> llvm-commits mailing list
> llvm-commits at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
>