Skip to content
  1. Jun 10, 2017
    • Geoff Berry's avatar
      [EarlyCSE] Add option to use MemorySSA for function simplification run of... · 3cca1da2
      Geoff Berry authored
      [EarlyCSE] Add option to use MemorySSA for function simplification run of EarlyCSE (off by default).
      
      Summary:
      Use MemorySSA for memory dependency checking in the EarlyCSE pass at the
      start of the function simplification portion of the pipeline.  We rely
      on the fact that GVNHoist runs just after this pass of EarlyCSE to
      amortize the MemorySSA construction cost since GVNHoist uses MemorySSA
      and EarlyCSE preserves it.
      
      This is turned off by default.  A follow-up change will turn it on to
      allow for easier reversion in case it breaks something.
      
      llvm-svn: 305146
      3cca1da2
  2. Jun 09, 2017
  3. Jun 08, 2017
  4. Jun 07, 2017
  5. Jun 06, 2017
    • Chandler Carruth's avatar
      Sort the remaining #include lines in include/... and lib/.... · 6bda14b3
      Chandler Carruth authored
      I did this a long time ago with a janky python script, but now
      clang-format has built-in support for this. I fed clang-format every
      line with a #include and let it re-sort things according to the precise
      LLVM rules for include ordering baked into clang-format these days.
      
      I've reverted a number of files where the results of sorting includes
      isn't healthy. Either places where we have legacy code relying on
      particular include ordering (where possible, I'll fix these separately)
      or where we have particular formatting around #include lines that
      I didn't want to disturb in this patch.
      
      This patch is *entirely* mechanical. If you get merge conflicts or
      anything, just ignore the changes in this patch and run clang-format
      over your #include lines in the files.
      
      Sorry for any noise here, but it is important to keep these things
      stable. I was seeing an increasing number of patches with irrelevant
      re-ordering of #include lines because clang-format was used. This patch
      at least isolates that churn, makes it easy to skip when resolving
      conflicts, and gets us to a clean baseline (again).
      
      llvm-svn: 304787
      6bda14b3
  6. Jun 03, 2017
  7. Jun 02, 2017
  8. Jun 01, 2017
  9. May 27, 2017
  10. May 26, 2017
  11. May 25, 2017
    • James Molloy's avatar
      [GVNSink] GVNSink pass · a9290632
      James Molloy authored
      This patch provides an initial prototype for a pass that sinks instructions based on GVN information, similar to GVNHoist. It is not yet ready for commiting but I've uploaded it to gather some initial thoughts.
      
      This pass attempts to sink instructions into successors, reducing static
      instruction count and enabling if-conversion.
      We use a variant of global value numbering to decide what can be sunk.
      Consider:
      
      [ %a1 = add i32 %b, 1  ]   [ %c1 = add i32 %d, 1  ]
      [ %a2 = xor i32 %a1, 1 ]   [ %c2 = xor i32 %c1, 1 ]
                       \           /
                 [ %e = phi i32 %a2, %c2 ]
                 [ add i32 %e, 4         ]
      
      GVN would number %a1 and %c1 differently because they compute different
      results - the VN of an instruction is a function of its opcode and the
      transitive closure of its operands. This is the key property for hoisting
      and CSE.
      
      What we want when sinking however is for a numbering that is a function of
      the *uses* of an instruction, which allows us to answer the question "if I
      replace %a1 with %c1, will it contribute in an equivalent way to all
      successive instructions?". The (new) PostValueTable class in GVN provides this
      mapping.
      
      This pass has some shown really impressive improvements especially for codesize already on internal benchmarks, so I have high hopes it can replace all the sinking logic in SimplifyCFG.
      
      Differential revision: https://reviews.llvm.org/D24805
      
      llvm-svn: 303850
      a9290632
  12. May 22, 2017
  13. May 20, 2017
  14. May 19, 2017
  15. May 16, 2017
  16. May 14, 2017
  17. May 13, 2017
  18. May 11, 2017
  19. May 10, 2017
  20. May 08, 2017
  21. May 04, 2017
  22. May 03, 2017
    • Reid Kleckner's avatar
      [IR] Abstract away ArgNo+1 attribute indexing as much as possible · a0b45f4b
      Reid Kleckner authored
      Summary:
      Do three things to help with that:
      - Add AttributeList::FirstArgIndex, which is an enumerator currently set
        to 1. It allows us to change the indexing scheme with fewer changes.
      - Add addParamAttr/removeParamAttr. This just shortens addAttribute call
        sites that would otherwise need to spell out FirstArgIndex.
      - Remove some attribute-specific getters and setters from Function that
        take attribute list indices.  Most of these were only used from
        BuildLibCalls, and doesNotAlias was only used to test or set if the
        return value is malloc-like.
      
      I'm happy to split the patch, but I think they are probably easier to
      review when taken together.
      
      This patch should be NFC, but it sets the stage to change the indexing
      scheme to this, which is more convenient when indexing into an array:
        0: func attrs
        1: retattrs
        2...: arg attrs
      
      Reviewers: chandlerc, pete, javed.absar
      
      Subscribers: david2050, llvm-commits
      
      Differential Revision: https://reviews.llvm.org/D32811
      
      llvm-svn: 302060
      a0b45f4b
  23. May 02, 2017
  24. May 01, 2017
Loading