Skip to content
  1. Jan 02, 2014
  2. Jan 01, 2014
  3. Dec 30, 2013
  4. Dec 28, 2013
  5. 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
  6. Dec 25, 2013
  7. Dec 20, 2013
  8. Dec 19, 2013
  9. Dec 18, 2013
  10. Dec 14, 2013
  11. Dec 13, 2013
  12. Dec 12, 2013
  13. Dec 10, 2013
  14. 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
  15. Dec 05, 2013
  16. 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
  17. Nov 28, 2013
  18. 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
  19. Nov 23, 2013
    • Chandler Carruth's avatar
      [PM] Complete the cross-layer interfaces with a Module-to-Function · c1ff9ed6
      Chandler Carruth authored
      proxy. This lets a function pass query a module analysis manager.
      However, the interface is const to indicate that only cached results can
      be safely queried.
      
      With this, I think the new pass manager is largely functionally complete
      for modules and analyses. Still lots to test, and need to generalize to
      SCCs and Loops, and need to build an adaptor layer to support the use of
      existing Pass objects in the new managers.
      
      llvm-svn: 195538
      c1ff9ed6
    • Chandler Carruth's avatar
      [PM] Rename TestAnalysisPass to TestFunctionAnalysis to clear the way · 2ad18583
      Chandler Carruth authored
      for a TestModuleAnalysis.
      
      llvm-svn: 195537
      2ad18583
    • Chandler Carruth's avatar
      [PM] Add support to the analysis managers to query explicitly for cached · de9afd84
      Chandler Carruth authored
      results.
      
      This is the last piece of infrastructure needed to effectively support
      querying *up* the analysis layers. The next step will be to introduce
      a proxy which provides access to those layers with appropriate use of
      const to direct queries to the safe interface.
      
      llvm-svn: 195525
      de9afd84
    • Chandler Carruth's avatar
      [PM] Switch the downward invalidation to be incremental where only the · bceeb229
      Chandler Carruth authored
      one function's analyses are invalidated at a time. Also switch the
      preservation of the proxy to *fully* preserve the lower (function)
      analyses.
      
      Combined, this gets both upward and downward analysis invalidation to
      a point I'm happy with:
      
      - A function pass invalidates its function analyses, and its parent's
        module analyses.
      - A module pass invalidates all of its functions' analyses including the
        set of which functions are in the module.
      - A function pass can preserve a module analysis pass.
      - If all function passes preserve a module analysis pass, that
        preservation persists. If any doesn't the module analysis is
        invalidated.
      - A module pass can opt into managing *all* function analysis
        invalidation itself or *none*.
      - The conservative default is none, and the proxy takes the maximally
        conservative approach that works even if the set of functions has
        changed.
      - If a module pass opts into managing function analysis invalidation it
        has to propagate the invalidation itself, the proxy just does nothing.
      
      The only thing really missing is a way to query for a cached analysis or
      nothing at all. With this, function passes can more safely request
      a cached module analysis pass without fear of it accidentally running
      part way through.
      
      llvm-svn: 195519
      bceeb229
  20. Nov 22, 2013
    • Chandler Carruth's avatar
      [PM] Teach the analysis managers to pass themselves as arguments to the · f2edc075
      Chandler Carruth authored
      run methods of the analysis passes.
      
      Also generalizes and re-uses the SFINAE for transformation passes so
      that users can write an analysis pass and only accept an analysis
      manager if that is useful to their pass.
      
      This completes the plumbing to make an analysis manager available
      through every pass's run method if desired so that passes no longer need
      to be constructed around them.
      
      llvm-svn: 195451
      f2edc075
    • Chandler Carruth's avatar
      [PM] Remove the IRUnitT typedef requirement for analysis passes. · bf950c0f
      Chandler Carruth authored
      Since the analysis managers were split into explicit function and module
      analysis managers, it is now completely trivial to specify this when
      building up the concept and model types explicitly, and it is impossible
      to end up with a type error at run time. We instantiate a template when
      registering a pass that will enforce the requirement at a type-system
      level, and we produce a dynamic error on all the other query paths to
      the analysis manager if the pass in question isn't registered.
      
      llvm-svn: 195447
      bf950c0f
    • Chandler Carruth's avatar
      [PM] Fix the analysis templates' usage of IRUnitT. · 5bf5e31c
      Chandler Carruth authored
      This is supposed to be the whole type of the IR unit, and so we
      shouldn't pass a pointer to it but rather the value itself. In turn, we
      need to provide a 'Module *' as that type argument (for example). This
      will become more relevant with SCCs or other units which may not be
      passed as a pointer type, but also brings consistency with the
      transformation pass templates.
      
      llvm-svn: 195445
      5bf5e31c
    • Michael Gottesman's avatar
Loading