Skip to content
  1. Sep 21, 2011
  2. Aug 16, 2011
    • Akira Hatanaka's avatar
      Fix handling of double precision loads and stores when Mips1 is targeted. · 2263c109
      Akira Hatanaka authored
      Mips1 does not support double precision loads or stores, therefore two single
      precision loads or stores must be used in place of these instructions. This 
      patch treats double precision loads and stores as if they are legal
      instructions until MCInstLowering, instead of generating the single precision
      instructions during instruction selection or Prolog/Epilog code insertion.
      
      Without the changes made in this patch, llc produces code that has the same 
      problem described in r137484 or bails out when
      MipsInstrInfo::storeRegToStackSlot or loadRegFromStackSlot is called before
      register allocation.
      
      llvm-svn: 137711
      2263c109
  3. Aug 12, 2011
    • Akira Hatanaka's avatar
      When constant double 0.0 is lowered, make sure 0 is copied directly from an · 7bd6e6eb
      Akira Hatanaka authored
      integer register to a floating point register. It is not valid to interpret
      the value of a floating pointer register as part of a double precision
      floating point value after a single precision floating point computational
      or move instruction stores its result to the register.
      
      - In the test case, the following code is generated before this patch is
        applied:
      mtc1  $zero, $f2    ; unformatted copy to $f2
      mov.s $f0, $f2      ; $f0 is in single format
      sdc1  $f12, 0($sp)
      mov.s $f1, $f2      ; $f1 is in single format
      c.eq.d  $f12, $f0   ; $f0 cannot be interpreted as double
      
      - The following code is generated after this patch is applied:
      mtc1  $zero, $f0    ; unformatted copy to $f0
      mtc1  $zero, $f1    ; unformatted copy to $f1
      c.eq.d  $f12, $f0   ; $f0 can be interpreted as double
      
      Bhanu Chetlapalli and Chris Dearman at MIPS technologies reported this bug and
      provided the test case.
      
      llvm-svn: 137484
      7bd6e6eb
  4. Jul 07, 2011
  5. Jun 24, 2011
  6. Jun 21, 2011
  7. Jun 09, 2011
  8. Jun 07, 2011
  9. Jun 02, 2011
  10. May 31, 2011
  11. May 28, 2011
  12. Apr 15, 2011
  13. Apr 04, 2011
  14. Apr 02, 2011
  15. Apr 01, 2011
  16. Mar 04, 2011
  17. Dec 23, 2010
  18. Dec 21, 2010
  19. Nov 12, 2010
  20. Sep 21, 2010
    • Chris Lattner's avatar
      fix a long standing wart: all the ComplexPattern's were being · 0e023ea0
      Chris Lattner authored
      passed the root of the match, even though only a few patterns
      actually needed this (one in X86, several in ARM [which should
      be refactored anyway], and some in CellSPU that I don't feel 
      like detangling).   Instead of requiring all ComplexPatterns to
      take the dead root, have targets opt into getting the root by
      putting SDNPWantRoot on the ComplexPattern.
      
      llvm-svn: 114471
      0e023ea0
  21. Sep 03, 2010
  22. Aug 19, 2010
  23. May 24, 2010
  24. Apr 17, 2010
    • Dan Gohman's avatar
      Use const qualifiers with TargetLowering. This eliminates several · 21cea8ac
      Dan Gohman authored
      const_casts, and it reinforces the design of the Target classes being
      immutable.
      
      SelectionDAGISel::IsLegalToFold is now a static member function, because
      PIC16 uses it in an unconventional way. There is more room for API
      cleanup here.
      
      And PIC16's AsmPrinter no longer uses TargetLowering.
      
      llvm-svn: 101635
      21cea8ac
  25. Mar 02, 2010
    • Chris Lattner's avatar
      Sink InstructionSelect() out of each target into SDISel, and rename it · f98f124a
      Chris Lattner authored
      DoInstructionSelection.  Inline "SelectRoot" into it from DAGISelHeader.
      Sink some other stuff out of DAGISelHeader into SDISel.
      
      Eliminate the various 'Indent' stuff from various targets, which dates
      to when isel was recursive.
      
       17 files changed, 114 insertions(+), 430 deletions(-)
      
      llvm-svn: 97555
      f98f124a
  26. Feb 09, 2010
  27. Feb 01, 2010
  28. Jan 19, 2010
  29. Jan 05, 2010
  30. Nov 25, 2009
  31. Nov 19, 2009
Loading