[PATCH] [SimplifyCFG] Be more aggressive

[James Molloy]

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.

James


REPOSITORY
  rL LLVM

http://reviews.llvm.org/D7507

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