Skip to content
  1. Oct 24, 2011
  2. Oct 23, 2011
    • Chandler Carruth's avatar
      Now that we have comparison on probabilities, add some static functions · fd7475e9
      Chandler Carruth authored
      to get important constant branch probabilities and use them for finding
      the best branch out of a set of possibilities.
      
      llvm-svn: 142762
      fd7475e9
    • Chandler Carruth's avatar
      Remove a commented out line of code that snuck by my auditing. · 446210b6
      Chandler Carruth authored
      llvm-svn: 142761
      446210b6
    • Chandler Carruth's avatar
      Completely re-write the algorithm behind MachineBlockPlacement based on · bd1be4d0
      Chandler Carruth authored
      discussions with Andy. Fundamentally, the previous algorithm is both
      counter productive on several fronts and prioritizing things which
      aren't necessarily the most important: static branch prediction.
      
      The new algorithm uses the existing loop CFG structure information to
      walk through the CFG itself to layout blocks. It coalesces adjacent
      blocks within the loop where the CFG allows based on the most likely
      path taken. Finally, it topologically orders the block chains that have
      been formed. This allows it to choose a (mostly) topologically valid
      ordering which still priorizes fallthrough within the structural
      constraints.
      
      As a final twist in the algorithm, it does violate the CFG when it
      discovers a "hot" edge, that is an edge that is more than 4x hotter than
      the competing edges in the CFG. These are forcibly merged into
      a fallthrough chain.
      
      Future transformations that need te be added are rotation of loop exit
      conditions to be fallthrough, and better isolation of cold block chains.
      I'm also planning on adding statistics to model how well the algorithm
      does at laying out blocks based on the probabilities it receives.
      
      The old tests mostly still pass, and I have some new tests to add, but
      the nested loops are still behaving very strangely. This almost seems
      like working-as-intended as it rotated the exit branch to be
      fallthrough, but I'm not convinced this is actually the best layout. It
      is well supported by the probabilities for loops we currently get, but
      those are pretty broken for nested loops, so this may change later.
      
      llvm-svn: 142743
      bd1be4d0
  3. Oct 21, 2011
    • Chandler Carruth's avatar
      Add loop aligning to MachineBlockPlacement based on review discussion so · 8b9737cb
      Chandler Carruth authored
      it's a bit more plausible to use this instead of CodePlacementOpt. The
      code for this was shamelessly stolen from CodePlacementOpt, and then
      trimmed down a bit. There doesn't seem to be much utility in returning
      true/false from this pass as we may or may not have rewritten all of the
      blocks. Also, the statistic of counting how many loops were aligned
      doesn't seem terribly important so I removed it. If folks would like it
      to be included, I'm happy to add it back.
      
      This was probably the most egregious of the missing features, and now
      I'm going to start gathering some performance numbers and looking at
      specific loop structures that have different layout between the two.
      
      Test is updated to include both basic loop alignment and nested loop
      alignment.
      
      llvm-svn: 142645
      8b9737cb
    • Chandler Carruth's avatar
      Implement a block placement pass based on the branch probability and · 10281425
      Chandler Carruth authored
      block frequency analyses. This differs substantially from the existing
      block-placement pass in LLVM:
      
      1) It operates on the Machine-IR in the CodeGen layer. This exposes much
         more (and more precise) information and opportunities. Also, the
         results are more stable due to fewer transforms ocurring after the
         pass runs.
      2) It uses the generalized probability and frequency analyses. These can
         model static heuristics, code annotation derived heuristics as well
         as eventual profile loading. By basing the optimization on the
         analysis interface it can work from any (or a combination) of these
         inputs.
      3) It uses a more aggressive algorithm, both building chains from tho
         bottom up to maximize benefit, and using an SCC-based walk to layout
         chains of blocks in a profitable ordering without O(N^2) iterations
         which the old pass involves.
      
      The pass is currently gated behind a flag, and not enabled by default
      because it still needs to grow some important features. Most notably, it
      needs to support loop aligning and careful layout of loop structures
      much as done by hand currently in CodePlacementOpt. Once it supports
      these, and has sufficient testing and quality tuning, it should replace
      both of these passes.
      
      Thanks to Nick Lewycky and Richard Smith for help authoring & debugging
      this, and to Jakob, Andy, Eric, Jim, and probably a few others I'm
      forgetting for reviewing and answering all my questions. Writing
      a backend pass is *sooo* much better now than it used to be. =D
      
      llvm-svn: 142641
      10281425
Loading