[PATCH] [SimplifyCFG] Be more aggressive

[hfinkel at anl.gov]

In http://reviews.llvm.org/D7507#122614, @jmolloy wrote:

> Hi Hal,
>
> I can make the comment change, no problem.
>
> With regards modelling, I think this is going to be a very difficult problem if we want to model more accurately. The penalty for speculating instructions is a function of the number and type of instructions speculated, the in-orderness of the CPU, the predictability of the branch condition, and probably a bunch of other factors too.
>
> I feel that, given how much better the optimizer can reason about things when they're in a single basic block, that for small sequences like this the speculated version should be the canonical form. Then CodeGenPrepare or something similarly nearer the backend can make a target-specific decision whether to expand it or not. So really, the heuristic here is mainly a cutoff to stop horribly expensive stuff from being speculated, but the backend should have the final say.
>
> That is, the indirect benefits outweigh the direct benefits, so more accurately modelling the direct cost in SimplifyCFG we may end up making the wrong decision.


Fair enough, but sometimes we need to take the "do no harm" approach. Nevertheless, it turns out my `P7` performance regression was a combination of a faulty script and a compiler crash, so we can ignore that (it is a good thing that I investigated it, however, because it turns out it was a serious regression). I think that we may need to return to the modeling question here, but I think we can move forward with this for now (all of my testing is neutral, both on PPC and on X86, with a speedup on x86). LGTM.

> James





REPOSITORY
  rL LLVM

http://reviews.llvm.org/D7507

EMAIL PREFERENCES
  http://reviews.llvm.org/settings/panel/emailpreferences/