Skip to content
  1. Nov 20, 2009
  2. Nov 19, 2009
    • David Greene's avatar
      · 50909c05
      David Greene authored
      Fix a small bug.
      
      Fix one case we missed to make sure we reserve registers from
      allocation.
      
      llvm-svn: 89376
      50909c05
    • David Greene's avatar
      · f37756d6
      David Greene authored
      Add support for spreading register allocation.
      
      Add a -linearscan-skip-count argument (default to 0) that tells the
      allocator to remember the last N registers it allocated and skip them
      when looking for a register candidate.  This tends to spread out
      register usage and free up post-allocation scheduling at the cost of
      slightly more register pressure.  The primary benefit is the ability
      to backschedule reloads.
      
      This is turned off by default.
      
      llvm-svn: 89356
      f37756d6
    • Lang Hames's avatar
      Added a new Spiller implementation which wraps LiveIntervals::addIntervalsForSpills. · 6912be4a
      Lang Hames authored
      All spiller calls in RegAllocLinearScan now go through the new Spiller interface.
      The "-new-spill-framework" command line option has been removed. To use the trivial in-place spiller you should now pass "-spiller=trivial -rewriter=trivial".
      (Note the trivial spiller/rewriter are only meant to serve as examples of the new in-place modification work. Enabling them will yield terrible, though hopefully functional, code).
      
      llvm-svn: 89311
      6912be4a
  3. 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
  4. Oct 25, 2009
  5. Oct 03, 2009
  6. Sep 26, 2009
  7. Sep 04, 2009
  8. Aug 23, 2009
  9. Aug 22, 2009
  10. Aug 01, 2009
  11. Jul 25, 2009
    • Daniel Dunbar's avatar
      More migration to raw_ostream, the water has dried up around the iostream hole. · 0dd5e1ed
      Daniel Dunbar authored
       - Some clients which used DOUT have moved to DEBUG. We are deprecating the
         "magic" DOUT behavior which avoided calling printing functions when the
         statement was disabled. In addition to being unnecessary magic, it had the
         downside of leaving code in -Asserts builds, and of hiding potentially
         unnecessary computations.
      
      llvm-svn: 77019
      0dd5e1ed
  12. Jul 14, 2009
  13. Jul 13, 2009
  14. Jul 11, 2009
  15. Jul 01, 2009
  16. Jun 30, 2009
    • Evan Cheng's avatar
      Add a bit IsUndef to MachineOperand. This indicates the def / use register... · 0dc101b8
      Evan Cheng authored
      Add a bit IsUndef to MachineOperand. This indicates the def / use register operand is defined by an implicit_def. That means it can def / use any register and passes (e.g. register scavenger) can feel free to ignore them.
      
      The register allocator, when it allocates a register to a virtual register defined by an implicit_def, can allocate any physical register without worrying about overlapping live ranges. It should mark all of operands of the said virtual register so later passes will do the right thing.
      
      This is not the best solution. But it should be a lot less fragile to having the scavenger try to track what is defined by implicit_def.
      
      llvm-svn: 74518
      0dc101b8
  17. Jun 18, 2009
    • Evan Cheng's avatar
      - Update register allocation hint after coalescing. This is done by the target... · 0e796035
      Evan Cheng authored
      - Update register allocation hint after coalescing. This is done by the target since the hint is target dependent. This is important for ARM register pair hints.
      - Register allocator should resolve the second part of the hint (register number) before passing it to the target since it knows virtual register to physical register mapping.
      - More fixes to get ARM load / store double word working.
      
      llvm-svn: 73671
      0e796035
  18. Jun 17, 2009
  19. Jun 15, 2009
    • Evan Cheng's avatar
      Part 1. · 1283c6a0
      Evan Cheng authored
      - Change register allocation hint to a pair of unsigned integers. The hint type is zero (which means prefer the register specified as second part of the pair) or entirely target dependent.
      - Allow targets to specify alternative register allocation orders based on allocation hint.
      
      Part 2.
      - Use the register allocation hint system to implement more aggressive load / store multiple formation.
      - Aggressively form LDRD / STRD. These are formed *before* register allocation. It has to be done this way to shorten live interval of base and offset registers. e.g.
      v1025 = LDR v1024, 0
      v1026 = LDR v1024, 0
      =>
      v1025,v1026 = LDRD v1024, 0
      
      If this transformation isn't done before allocation, v1024 will overlap v1025 which means it more difficult to allocate a register pair.
      
      - Even with the register allocation hint, it may not be possible to get the desired allocation. In that case, the post-allocation load / store multiple pass must fix the ldrd / strd instructions. They can either become ldm / stm instructions or back to a pair of ldr / str instructions.
      
      This is work in progress, not yet enabled.
      
      llvm-svn: 73381
      1283c6a0
  20. Jun 14, 2009
  21. Jun 04, 2009
  22. Jun 02, 2009
  23. May 18, 2009
  24. May 13, 2009
  25. May 06, 2009
  26. May 03, 2009
    • Evan Cheng's avatar
      In some rare cases, the register allocator can spill registers but end up not... · 210fc62a
      Evan Cheng authored
      In some rare cases, the register allocator can spill registers but end up not utilizing registers at all. The fundamental problem is linearscan's backtracking can end up freeing more than one allocated registers. However,  reloads and restores might be folded into uses / defs and freed registers might not be used at all.
      
      VirtRegMap keeps track of allocations so it knows what's not used. As a horrible hack, the stack coloring can color spill slots with *free* registers. That is, it replace reload and spills with copies from and to the free register. It unfold instructions that load and store the spill slot and replace them with register using variants.
      
      Not yet enabled. This is part 1. More coming.
      
      llvm-svn: 70787
      210fc62a
  27. May 01, 2009
  28. Apr 29, 2009
  29. Apr 22, 2009
    • Evan Cheng's avatar
      It has finally happened. Spiller is now using live interval info. · 1a99a5f5
      Evan Cheng authored
      This fixes a very subtle bug. vr defined by an implicit_def is allowed overlap with any register since it doesn't actually modify anything. However, if it's used as a two-address use, its live range can be extended and it can be spilled. The spiller must take care not to emit a reload for the vn number that's defined by the implicit_def. This is both a correctness and performance issue.
      
      llvm-svn: 69743
      1a99a5f5
  30. Apr 20, 2009
    • Evan Cheng's avatar
      - Remove an arbitrary spill weight tweak that should not have been there. · 5dd2e29b
      Evan Cheng authored
      - Find more reloads from SS.
      
      llvm-svn: 69606
      5dd2e29b
    • Evan Cheng's avatar
      Added a linearscan register allocation optimization. When the register... · d67efaa8
      Evan Cheng authored
      Added a linearscan register allocation optimization. When the register allocator spill an interval with multiple uses in the same basic block, it creates a different virtual register for each of the reloads. e.g.
      
      	%reg1498<def> = MOV32rm %reg1024, 1, %reg0, 12, %reg0, Mem:LD(4,4) [sunkaddr39 + 0]
              %reg1506<def> = MOV32rm %reg1024, 1, %reg0, 8, %reg0, Mem:LD(4,4) [sunkaddr42 + 0]
              %reg1486<def> = MOV32rr %reg1506
              %reg1486<def> = XOR32rr %reg1486, %reg1498, %EFLAGS<imp-def,dead>
              %reg1510<def> = MOV32rm %reg1024, 1, %reg0, 4, %reg0, Mem:LD(4,4) [sunkaddr45 + 0]
      
      =>
      
              %reg1498<def> = MOV32rm %reg2036, 1, %reg0, 12, %reg0, Mem:LD(4,4) [sunkaddr39 + 0]
              %reg1506<def> = MOV32rm %reg2037, 1, %reg0, 8, %reg0, Mem:LD(4,4) [sunkaddr42 + 0]
              %reg1486<def> = MOV32rr %reg1506
              %reg1486<def> = XOR32rr %reg1486, %reg1498, %EFLAGS<imp-def,dead>
              %reg1510<def> = MOV32rm %reg2038, 1, %reg0, 4, %reg0, Mem:LD(4,4) [sunkaddr45 + 0]
      
      From linearscan's point of view, each of reg2036, 2037, and 2038 are separate registers, each is "killed" after a single use. The reloaded register is available and it's often clobbered right away. e.g. In thise case reg1498 is allocated EAX while reg2036 is allocated RAX. This means we end up with multiple reloads from the same stack slot in the same basic block.
      
      Now linearscan recognize there are other reloads from same SS in the same BB. So it'll "downgrade" RAX (and its aliases) after reg2036 is allocated until the next reload (reg2037) is done. This greatly increase the likihood reloads from SS are reused.
      
      This speeds up sha1 from OpenSSL by 5.8%. It is also an across the board win for SPEC2000 and 2006.
      
      llvm-svn: 69585
      d67efaa8
Loading