Skip to content
  1. Jan 04, 2013
  2. Jan 03, 2013
  3. Jan 02, 2013
  4. Dec 22, 2012
  5. Dec 21, 2012
    • Anna Zaks's avatar
      [analyzer] Re-apply r170826 and make the dumping of the GallGraph · 1ee76c1b
      Anna Zaks authored
      deterministic.
      
      Commit message for r170826:
      
      [analyzer] Traverse the Call Graph in topological order.
      
      Modify the call graph by removing the parentless nodes. Instead all
      nodes are children of root to ensure they are all reachable. Remove the
      tracking of nodes that are "top level" or global. This information is
      not used and can be obtained from the Decls stored inside
      CallGraphNodes.
      
      Instead of existing ordering hacks, analyze the functions in topological
      order over the Call Graph.
      
      Together with the addition of devirtualizable ObjC message sends and
      blocks to the call graph, this gives around 6% performance improvement
      on several large ObjC benchmarks.
      
      llvm-svn: 170906
      1ee76c1b
    • Roman Divacky's avatar
      Remove duplicate includes. · 241f4511
      Roman Divacky authored
      llvm-svn: 170903
      241f4511
    • Anna Zaks's avatar
      [analyzer] Address Jordan's nitpicks as per code review of r170625. · 9747febb
      Anna Zaks authored
      llvm-svn: 170832
      9747febb
    • Rafael Espindola's avatar
      Revert r170826. The output of · e7ec558f
      Rafael Espindola authored
      ./bin/clang -cc1 -internal-isystem /home/espindola/llvm/build/lib/clang/3.3/include/ -analyze -analyzer-checker=debug.DumpCallGraph /home/espindola/llvm/clang/test/Analysis/debug-CallGraph.c -fblocks
      
      changes in each run.
      
      llvm-svn: 170829
      e7ec558f
    • Anna Zaks's avatar
      [analyzer] Traverse the Call Graph in topological order. · 77ca7f1b
      Anna Zaks authored
      Modify the call graph by removing the parentless nodes. Instead all
      nodes are children of root to ensure they are all reachable. Remove the
      tracking of nodes that are "top level" or global. This information is
      not used and can be obtained from the Decls stored inside
      CallGraphNodes.
      
      Instead of existing ordering hacks, analyze the functions in topological
      order over the Call Graph.
      
      Together with the addition of devirtualizable ObjC message sends and
      blocks to the call graph, this gives around 6% performance improvement
      on several large ObjC benchmarks.
      
      llvm-svn: 170826
      77ca7f1b
    • Anna Zaks's avatar
      [analyzer] Add blocks and ObjC messages to the call graph. · 5c32dfc5
      Anna Zaks authored
      This paves the road for constructing a better function dependency graph.
      If we analyze a function before the functions it calls and inlines,
      there is more opportunity for optimization.
      
      Note, we add call edges to the called methods that correspond to
      function definitions (declarations with bodies).
      
      llvm-svn: 170825
      5c32dfc5
  6. Dec 20, 2012
  7. Dec 19, 2012
  8. Dec 17, 2012
    • Argyrios Kyrtzidis's avatar
    • Anna Zaks's avatar
      [analyzer] Tweak the NumFunctionsAnalyzed stat so that it's more useful. · ad3704c9
      Anna Zaks authored
      llvm-svn: 170362
      ad3704c9
    • Anna Zaks's avatar
      [analyzer] Implement "do not inline large functions many times" · d53182b0
      Anna Zaks authored
      performance heuristic
      
      After inlining a function with more than 13 basic blocks 32 times, we
      are not going to inline it anymore. The idea is that inlining large
      functions leads to drastic performance implications. Since the function
      has already been inlined, we know that we've analyzed it in many
      contexts. 
      
      The following metrics are used:
       - Large function is a function with more than 13 basic blocks (we
      should switch to another metric, like cyclomatic complexity)
       - We consider that we've inlined a function many times if it's been
      inlined 32 times. This number is configurable with -analyzer-config
      max-times-inline-large=xx
      
      This heuristic addresses a performance regression introduced with
      inlining on one benchmark. The analyzer on this benchmark became 60
      times slower with inlining turned on. The heuristic allows us to analyze
      it in 24% of the time. The performance improvements on the other
      benchmarks I've tested with are much lower - under 10%, which is
      expected.
      
      llvm-svn: 170361
      d53182b0
  9. Dec 14, 2012
  10. Dec 13, 2012
  11. Dec 12, 2012
  12. Dec 11, 2012
  13. Dec 07, 2012
  14. Dec 06, 2012
Loading