Skip to content
  1. Jan 05, 2014
  2. Jan 03, 2014
  3. Jan 02, 2014
  4. Jan 01, 2014
  5. Dec 30, 2013
  6. Dec 28, 2013
  7. Dec 27, 2013
    • Chandler Carruth's avatar
      Introduce a simple line-by-line iterator type into the Support library. · f8c5281c
      Chandler Carruth authored
      This is an iterator which you can build around a MemoryBuffer. It will
      iterate through the non-empty, non-comment lines of the buffer as
      a forward iterator. It should be small and reasonably fast (although it
      could be made much faster if anyone cares, I don't really...).
      
      This will be used to more simply support the text-based sample
      profile file format, and is largely based on the original patch by
      Diego. I've re-worked the style of it and separated it from the work of
      producing a MemoryBuffer from a file which both simplifies the interface
      and makes it easier to test.
      
      The style of the API follows the C++ standard naming conventions to fit
      in better with iterators in general, much like the Path and FileSystem
      interfaces follow standard-based naming conventions.
      
      llvm-svn: 198068
      f8c5281c
  8. Dec 25, 2013
  9. Dec 20, 2013
  10. Dec 19, 2013
  11. Dec 18, 2013
  12. Dec 14, 2013
  13. Dec 13, 2013
  14. Dec 12, 2013
  15. Dec 10, 2013
  16. Dec 06, 2013
    • Kostya Serebryany's avatar
      [asan] rewrite asan's stack frame layout · 4fb7801b
      Kostya Serebryany authored
      Summary:
      Rewrite asan's stack frame layout.
      First, most of the stack layout logic is moved into a separte file
      to make it more testable and (potentially) useful for other projects.
      Second, make the frames more compact by using adaptive redzones
      (smaller for small objects, larger for large objects).
      Third, try to minimized gaps due to large alignments (this is hypothetical since
      today we don't see many stack vars aligned by more than 32).
      
      The frames indeed become more compact, but I'll still need to run more benchmarks
      before committing, but I am sking for review now to get early feedback.
      
      This change will be accompanied by a trivial change in compiler-rt tests
      to match the new frame sizes.
      
      Reviewers: samsonov, dvyukov
      
      Reviewed By: samsonov
      
      CC: llvm-commits
      
      Differential Revision: http://llvm-reviews.chandlerc.com/D2324
      
      llvm-svn: 196568
      4fb7801b
  17. Dec 05, 2013
  18. Dec 02, 2013
    • Diego Novillo's avatar
      Fix dominator descendants for unreachable blocks. · ee592429
      Diego Novillo authored
      When a block is unreachable, asking its dom tree descendants should
      return the empty set. However, the computation of the descendants
      was causing a segmentation fault because the dom tree node we get
      from the basic block is initially NULL.
      
      Fixed by adding a test for a valid dom tree node before we iterate.
      
      The patch also adds some unit tests to the existing dom tree tests.
      
      llvm-svn: 196099
      ee592429
  19. Nov 28, 2013
  20. Nov 26, 2013
    • Chandler Carruth's avatar
      [PM] Split the CallGraph out from the ModulePass which creates the · 6378cf53
      Chandler Carruth authored
      CallGraph.
      
      This makes the CallGraph a totally generic analysis object that is the
      container for the graph data structure and the primary interface for
      querying and manipulating it. The pass logic is separated into its own
      class. For compatibility reasons, the pass provides wrapper methods for
      most of the methods on CallGraph -- they all just forward.
      
      This will allow the new pass manager infrastructure to provide its own
      analysis pass that constructs the same CallGraph object and makes it
      available. The idea is that in the new pass manager, the analysis pass's
      'run' method returns a concrete analysis 'result'. Here, that result is
      a 'CallGraph'. The 'run' method will typically do only minimal work,
      deferring much of the work into the implementation of the result object
      in order to be lazy about computing things, but when (like DomTree)
      there is *some* up-front computation, the analysis does it prior to
      handing the result back to the querying pass.
      
      I know some of this is fairly ugly. I'm happy to change it around if
      folks can suggest a cleaner interim state, but there is going to be some
      amount of unavoidable ugliness during the transition period. The good
      thing is that this is very limited and will naturally go away when the
      old pass infrastructure goes away. It won't hang around to bother us
      later.
      
      Next up is the initial new-PM-style call graph analysis. =]
      
      llvm-svn: 195722
      6378cf53
  21. Nov 23, 2013
Loading