Skip to content
  1. Dec 28, 2010
  2. Dec 27, 2010
    • Cameron Zwarich's avatar
      Change an assertion to assert what the code actually relies upon. · 5e5cfbe8
      Cameron Zwarich authored
      llvm-svn: 122586
      5e5cfbe8
    • Cameron Zwarich's avatar
      Land a first cut at StrongPHIElimination. There are only 5 new test failures · 25d046ce
      Cameron Zwarich authored
      when running without the verifier, and I have not yet checked them to see if
      the new results are still correct. There are more verifier failures, but they
      all seem to be additional occurrences of verifier failures that occur with the
      existing PHIElimination pass. There are a few obvious issues with the code:
      
      1) It doesn't properly update the register equivalence classes during copy
      insertion, and instead recomputes them before merging live intervals and
      renaming registers. I wanted to keep this first patch simple for debugging
      purposes, but it shouldn't be very hard to do this.
      
      2) It doesn't mix the renaming and live interval merging with the copy insertion
      process, which leads to a lot of virtual register churn. Virtual registers and
      live intervals are created, only to later be merged into others. The code should
      be smarter and only create a new virtual register if there is no existing
      register in the same congruence class.
      
      3) In one place the code uses a DenseMap per basic block, which is unnecessary
      heap allocation. There should be an inline storage version of DenseMap.
      
      I did a quick compile-time test of running llc on 403.gcc with and without
      StrongPHIElimination. It is slightly slower with StrongPHIElimination, because
      the small decrease in the coalescer runtime can't beat the increase in phi
      elimination runtime. Perhaps fixing the above performance issues will narrow
      the gap.
      
      I also haven't yet run any tests of the quality of the generated code.
      
      llvm-svn: 122582
      25d046ce
  3. Dec 24, 2010
  4. Dec 21, 2010
    • Cameron Zwarich's avatar
      Incremental progress towards a new implementation of StrongPHIElimination. Most · 79ebc718
      Cameron Zwarich authored
      of the problems with my last attempt were in the updating of LiveIntervals
      rather than the coalescing itself. Therefore, I decided to get that right first
      by essentially reimplementing the existing PHIElimination using LiveIntervals.
      
      It works correctly, with only a few tests failing (which may not be legitimate
      failures) and no new verifier failures (at least as far as I can tell, I didn't
      count the number per file).
      
      llvm-svn: 122321
      79ebc718
  5. Dec 05, 2010
  6. Dec 03, 2010
  7. Oct 19, 2010
    • Owen Anderson's avatar
      Get rid of static constructors for pass registration. Instead, every pass... · 6c18d1aa
      Owen Anderson authored
      Get rid of static constructors for pass registration.  Instead, every pass exposes an initializeMyPassFunction(), which
      must be called in the pass's constructor.  This function uses static dependency declarations to recursively initialize
      the pass's dependencies.
      
      Clients that only create passes through the createFooPass() APIs will require no changes.  Clients that want to use the
      CommandLine options for passes will need to manually call the appropriate initialization functions in PassInitialization.h
      before parsing commandline arguments.
      
      I have tested this with all standard configurations of clang and llvm-gcc on Darwin.  It is possible that there are problems
      with the static dependencies that will only be visible with non-standard options.  If you encounter any crash in pass
      registration/creation, please send the testcase to me directly.
      
      llvm-svn: 116820
      6c18d1aa
  8. Oct 12, 2010
  9. Oct 08, 2010
  10. Aug 23, 2010
  11. Aug 06, 2010
  12. Jul 11, 2010
  13. Jun 26, 2010
    • Jakob Stoklund Olesen's avatar
      Don't track kills in VNInfo. Use interval ends instead. · 55d738e2
      Jakob Stoklund Olesen authored
      The VNInfo.kills vector was almost unused except for all the code keeping it
      updated. The few places using it were easily rewritten to check for interval
      ends instead.
      
      The two new methods LiveInterval::killedAt and killedInRange are replacements.
      
      This brings us down to 3 independent data structures tracking kills.
      
      llvm-svn: 106905
      55d738e2
  14. May 06, 2010
  15. Feb 10, 2010
  16. Feb 09, 2010
  17. Jan 05, 2010
  18. Dec 18, 2009
  19. Nov 04, 2009
    • Lang Hames's avatar
      The Indexes Patch. · 05fb9637
      Lang Hames authored
      This introduces a new pass, SlotIndexes, which is responsible for numbering
      instructions for register allocation (and other clients). SlotIndexes numbering
      is designed to match the existing scheme, so this patch should not cause any
      changes in the generated code.
      
      For consistency, and to avoid naming confusion, LiveIndex has been renamed
      SlotIndex.
      
      The processImplicitDefs method of the LiveIntervals analysis has been moved
      into its own pass so that it can be run prior to SlotIndexes. This was
      necessary to match the existing numbering scheme.
      
      llvm-svn: 85979
      05fb9637
  20. Oct 25, 2009
  21. Oct 03, 2009
  22. Sep 09, 2009
  23. Sep 04, 2009
  24. Aug 23, 2009
  25. Aug 11, 2009
  26. Aug 01, 2009
  27. Jul 09, 2009
    • Lang Hames's avatar
      Improved tracking of value number kills. VN kills are now represented · dab7b06d
      Lang Hames authored
      as an (index,bool) pair. The bool flag records whether the kill is a
      PHI kill or not. This code will be used to enable splitting of live
      intervals containing PHI-kills.
      
      A slight change to live interval weights introduced an extra spill
      into lsr-code-insertion (outside the critical sections). The test 
      condition has been updated to reflect this.
      
      llvm-svn: 75097
      dab7b06d
  28. Jun 17, 2009
  29. Jun 02, 2009
  30. Oct 12, 2008
  31. Oct 04, 2008
  32. Oct 03, 2008
  33. Oct 02, 2008
    • Owen Anderson's avatar
      Use a multimap rather than a map for holding the list of copies to insert, so... · c5b45fec
      Owen Anderson authored
      Use a multimap rather than a map for holding the list of copies to insert, so we don't lose copies when two of them have
      the same source.  I don't know what I was thinking when I wrote this originally.
      Note: There's probably a more efficient way to do this, but I need to think about it some more, and about what determinism
      guarantees need to be present.
      
      llvm-svn: 56964
      c5b45fec
  34. Oct 01, 2008
Loading