Skip to content
  1. Nov 13, 2011
  2. Oct 05, 2011
    • Jakob Stoklund Olesen's avatar
      Also add <imp-use,kill> flags for redefined super-registers. · d5d39bb0
      Jakob Stoklund Olesen authored
      For example:
      
        %vreg10:dsub_0<def,undef> = COPY %vreg1
        %vreg10:dsub_1<def> = COPY %vreg2
      
      is rewritten as:
      
        %D2<def> = COPY %D0, %Q1<imp-def>
        %D3<def> = COPY %D1, %Q1<imp-use,kill>, %Q1<imp-def>
      
      The first COPY doesn't care about the previous value of %Q1, so it
      doesn't read that register.
      
      The second COPY is a partial redefinition of %Q1, so it implicitly kills
      and redefines that register.
      
      This makes it possible to recognize instructions that can harmlessly
      clobber the full super-register.  The write and don't read the
      super-register.
      
      llvm-svn: 141139
      d5d39bb0
  3. Sep 15, 2011
  4. May 06, 2011
  5. Apr 27, 2011
  6. Mar 31, 2011
  7. Mar 23, 2011
  8. Feb 18, 2011
  9. Jan 10, 2011
  10. Jan 09, 2011
  11. Nov 16, 2010
  12. Oct 08, 2010
  13. Jul 22, 2010
  14. Feb 26, 2010
    • Jakob Stoklund Olesen's avatar
      Use the right floating point load/store instructions in PPCInstrInfo::foldMemoryOperandImpl(). · ddbf7a85
      Jakob Stoklund Olesen authored
      The PowerPC floating point registers can represent both f32 and f64 via the
      two register classes F4RC and F8RC. F8RC is considered a subclass of F4RC to
      allow cross-class coalescing. This coalescing only affects whether registers
      are spilled as f32 or f64.
      
      Spill slots must be accessed with load/store instructions corresponding to the
      class of the spilled register. PPCInstrInfo::foldMemoryOperandImpl was looking
      at the instruction opcode which is wrong.
      
      X86 has similar floating point register classes, but doesn't try to fold
      memory operands, so there is no problem there.
      
      llvm-svn: 97262
      ddbf7a85
  15. Feb 10, 2010
  16. Jan 05, 2010
  17. Nov 12, 2009
    • David Greene's avatar
      · 1fbe0544
      David Greene authored
      Add a bool flag to StackObjects telling whether they reference spill
      slots.  The AsmPrinter will use this information to determine whether to
      print a spill/reload comment.
      
      Remove default argument values.  It's too easy to pass a wrong argument
      value when multiple arguments have default values.  Make everything
      explicit to trap bugs early.
      
      Update all targets to adhere to the new interfaces..
      
      llvm-svn: 87022
      1fbe0544
  18. 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
  19. Oct 17, 2009
  20. Aug 23, 2009
  21. Jul 24, 2009
  22. 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
  23. Jun 14, 2009
  24. May 04, 2009
  25. 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
  26. Mar 31, 2009
  27. Mar 14, 2009
  28. Mar 13, 2009
  29. Mar 11, 2009
  30. Mar 09, 2009
  31. Mar 08, 2009
  32. Feb 28, 2009
  33. Feb 26, 2009
Loading