Skip to content
  1. May 19, 2010
  2. May 18, 2010
  3. May 17, 2010
  4. May 15, 2010
    • Evan Cheng's avatar
      Teach two-address pass to do some coalescing while eliminating REG_SEQUENCE · 8c2d062e
      Evan Cheng authored
      instructions.
      
      e.g.
      %reg1026<def> = VLDMQ %reg1025<kill>, 260, pred:14, pred:%reg0
      %reg1027<def> = EXTRACT_SUBREG %reg1026, 6
      %reg1028<def> = EXTRACT_SUBREG %reg1026<kill>, 5
      ...
      %reg1029<def> = REG_SEQUENCE %reg1028<kill>, 5, %reg1027<kill>, 6, %reg1028, 7, %reg1027, 8, %reg1028, 9, %reg1027, 10, %reg1030<kill>, 11, %reg1032<kill>, 12
      
      After REG_SEQUENCE is eliminated, we are left with:
      
      %reg1026<def> = VLDMQ %reg1025<kill>, 260, pred:14, pred:%reg0
      %reg1029:6<def> = EXTRACT_SUBREG %reg1026, 6
      %reg1029:5<def> = EXTRACT_SUBREG %reg1026<kill>, 5
      
      The regular coalescer will not be able to coalesce reg1026 and reg1029 because it doesn't
      know how to combine sub-register indices 5 and 6. Now 2-address pass will consult the
      target whether sub-registers 5 and 6 of reg1026 can be combined to into a larger
      sub-register (or combined to be reg1026 itself as is the case here). If it is possible, 
      it will be able to replace references of reg1026 with reg1029 + the larger sub-register
      index.
      
      llvm-svn: 103835
      8c2d062e
  5. May 13, 2010
  6. May 12, 2010
  7. May 11, 2010
  8. May 10, 2010
  9. May 06, 2010
  10. May 05, 2010
  11. Mar 23, 2010
  12. Mar 03, 2010
  13. Mar 02, 2010
  14. Feb 11, 2010
  15. Feb 10, 2010
  16. Feb 09, 2010
  17. Jan 05, 2010
  18. Dec 03, 2009
  19. Nov 18, 2009
    • Jakob Stoklund Olesen's avatar
      Fix PR5300. · 575c3f3d
      Jakob Stoklund Olesen authored
      When TwoAddressInstructionPass deletes a dead instruction, make sure that all
      register kills are accounted for. The 2-addr register does not get special
      treatment.
      
      llvm-svn: 89246
      575c3f3d
  20. Nov 14, 2009
  21. Oct 25, 2009
  22. Oct 10, 2009
    • Dan Gohman's avatar
      Factor out LiveIntervalAnalysis' code to determine whether an instruction · 87b02d5b
      Dan Gohman authored
      is trivially rematerializable and integrate it into
      TargetInstrInfo::isTriviallyReMaterializable. This way, all places that
      need to know whether an instruction is rematerializable will get the
      same answer.
      
      This enables the useful parts of the aggressive-remat option by
      default -- using AliasAnalysis to determine whether a memory location
      is invariant, and removes the questionable parts -- rematting operations
      with virtual register inputs that may not be live everywhere.
      
      llvm-svn: 83687
      87b02d5b
  23. Sep 03, 2009
    • Bob Wilson's avatar
      Overhaul the TwoAddressInstructionPass to simplify the logic, especially · 5c7d9ca5
      Bob Wilson authored
      for the complicated case where one register is tied to multiple destinations.
      This avoids the extra scan of instruction operands that was introduced by
      my recent change.  I also pulled some code out into a separate
      TryInstructionTransform method, added more comments, and renamed some
      variables.
      
      Besides all those changes, this takes care of a FIXME in the code regarding
      an assumption about there being a single tied use of a register when
      converting to a 3-address form.  I'm not aware of cases where that assumption
      is violated, but the code now only attempts to transform an instruction,
      either by commuting its operands or by converting to a 3-address form,
      for the simple case where there is a single pair of tied operands.
      
      llvm-svn: 80945
      5c7d9ca5
  24. Sep 02, 2009
  25. Sep 01, 2009
  26. Aug 31, 2009
  27. Aug 23, 2009
  28. Aug 07, 2009
  29. Aug 01, 2009
  30. 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
  31. Jul 20, 2009
  32. Jul 16, 2009
  33. Jul 11, 2009
Loading