Skip to content
  1. Nov 29, 2007
  2. Nov 28, 2007
  3. Nov 17, 2007
    • Evan Cheng's avatar
      Live interval splitting: · 8e223793
      Evan Cheng authored
      When a live interval is being spilled, rather than creating short, non-spillable
      intervals for every def / use, split the interval at BB boundaries. That is, for
      every BB where the live interval is defined or used, create a new interval that
      covers all the defs and uses in the BB.
      
      This is designed to eliminate one common problem: multiple reloads of the same
      value in a single basic block. Note, it does *not* decrease the number of spills
      since no copies are inserted so the split intervals are *connected* through
      spill and reloads (or rematerialization). The newly created intervals can be
      spilled again, in that case, since it does not span multiple basic blocks, it's
      spilled in the usual manner. However, it can reuse the same stack slot as the
      previously split interval.
      
      This is currently controlled by -split-intervals-at-bb.
      
      llvm-svn: 44198
      8e223793
  4. Nov 15, 2007
  5. Nov 14, 2007
    • Evan Cheng's avatar
      Clean up sub-register implementation by moving subReg information back to · 7f02cfa5
      Evan Cheng authored
      MachineOperand auxInfo. Previous clunky implementation uses an external map
      to track sub-register uses. That works because register allocator uses
      a new virtual register for each spilled use. With interval splitting (coming
      soon), we may have multiple uses of the same register some of which are
      of using different sub-registers from others. It's too fragile to constantly
      update the information.
      
      llvm-svn: 44104
      7f02cfa5
  6. Nov 12, 2007
  7. Nov 07, 2007
  8. Nov 06, 2007
  9. Nov 05, 2007
  10. Nov 03, 2007
    • Evan Cheng's avatar
      There are times when the coalescer would not coalesce away a copy but the copy · 66298e22
      Evan Cheng authored
      can be eliminated by the allocator is the destination and source targets the
      same register. The most common case is when the source and destination registers
      are in different class. For example, on x86 mov32to32_ targets GR32_ which
      contains a subset of the registers in GR32.
      
      The allocator can do 2 things:
      1. Set the preferred allocation for the destination of a copy to that of its source.
      2. After allocation is done, change the allocation of a copy destination (if
         legal) so the copy can be eliminated.
      
      This eliminates 443 extra moves from 403.gcc.
      
      llvm-svn: 43662
      66298e22
  11. Oct 17, 2007
  12. Oct 12, 2007
  13. Oct 08, 2007
  14. Oct 03, 2007
  15. Sep 14, 2007
  16. Sep 06, 2007
  17. Sep 05, 2007
  18. Aug 30, 2007
  19. Aug 29, 2007
  20. Aug 16, 2007
  21. Aug 14, 2007
  22. Aug 11, 2007
  23. Aug 08, 2007
  24. Jun 27, 2007
  25. Jun 19, 2007
    • Dan Gohman's avatar
      Replace M_REMATERIALIZIBLE and the newly-added isOtherReMaterializableLoad · 9e820649
      Dan Gohman authored
      with a general target hook to identify rematerializable instructions. Some
      instructions are only rematerializable with specific operands, such as loads
      from constant pools, while others are always rematerializable. This hook
      allows both to be identified as being rematerializable with the same
      mechanism.
      
      llvm-svn: 37644
      9e820649
  26. Jun 14, 2007
  27. Jun 08, 2007
  28. May 14, 2007
  29. May 03, 2007
  30. May 02, 2007
  31. May 01, 2007
  32. Apr 26, 2007
Loading