Skip to content
  1. Jul 01, 2009
  2. 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
  3. 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
  4. Jun 17, 2009
  5. 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
  6. Jun 14, 2009
  7. Jun 04, 2009
  8. Jun 02, 2009
  9. May 18, 2009
  10. May 13, 2009
  11. May 06, 2009
  12. 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
  13. May 01, 2009
  14. Apr 29, 2009
  15. 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
  16. 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
  17. Mar 23, 2009
  18. Mar 13, 2009
  19. Mar 11, 2009
  20. Jan 20, 2009
  21. Jan 05, 2009
  22. Oct 29, 2008
  23. Oct 23, 2008
    • Evan Cheng's avatar
      Committing a good chunk of the pre-register allocation live interval splitting... · d0d0317b
      Evan Cheng authored
      Committing a good chunk of the pre-register allocation live interval splitting pass. It's handling simple cases and appear to do good things. Next: avoid splitting an interval multiple times; renumber registers when possible; record stack slot live intervals for coloring; rematerialize defs when possible.
      
      llvm-svn: 58044
      d0d0317b
  24. Oct 14, 2008
  25. Oct 07, 2008
  26. Sep 30, 2008
  27. Sep 24, 2008
  28. Sep 20, 2008
Loading