Skip to content
  1. Jun 02, 2010
  2. May 29, 2010
  3. May 21, 2010
    • Evan Cheng's avatar
      - Change MachineInstr::findRegisterDefOperandIdx so it can also look for defs · 3858451e
      Evan Cheng authored
      that are aliases of the specified register.
      - Rename modifiesRegister to definesRegister since it's looking a def of the
      specific register or one of its super-registers. It's not looking for def of a
      sub-register or alias that could change the specified register.
      - Added modifiesRegister to look for defs of aliases.
      
      llvm-svn: 104377
      3858451e
  4. May 19, 2010
  5. May 18, 2010
  6. May 17, 2010
  7. 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
  8. May 13, 2010
  9. May 12, 2010
  10. May 11, 2010
  11. May 10, 2010
  12. May 06, 2010
  13. May 05, 2010
  14. Mar 23, 2010
  15. Mar 03, 2010
  16. Mar 02, 2010
  17. Feb 11, 2010
  18. Feb 10, 2010
  19. Feb 09, 2010
  20. Jan 05, 2010
  21. Dec 03, 2009
  22. 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
  23. Nov 14, 2009
  24. Oct 25, 2009
  25. 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
  26. 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
  27. Sep 02, 2009
  28. Sep 01, 2009
  29. Aug 31, 2009
  30. Aug 23, 2009
  31. Aug 07, 2009
  32. Aug 01, 2009
Loading