Skip to content
  1. Sep 21, 2010
  2. Sep 05, 2010
    • Chris Lattner's avatar
      implement rdar://6653118 - fastisel should fold loads where possible. · eeba0c73
      Chris Lattner authored
      Since mem2reg isn't run at -O0, we get a ton of reloads from the stack,
      for example, before, this code:
      
      int foo(int x, int y, int z) {
        return x+y+z;
      }
      
      used to compile into:
      
      _foo:                                   ## @foo
      	subq	$12, %rsp
      	movl	%edi, 8(%rsp)
      	movl	%esi, 4(%rsp)
      	movl	%edx, (%rsp)
      	movl	8(%rsp), %edx
      	movl	4(%rsp), %esi
      	addl	%edx, %esi
      	movl	(%rsp), %edx
      	addl	%esi, %edx
      	movl	%edx, %eax
      	addq	$12, %rsp
      	ret
      
      Now we produce:
      
      _foo:                                   ## @foo
      	subq	$12, %rsp
      	movl	%edi, 8(%rsp)
      	movl	%esi, 4(%rsp)
      	movl	%edx, (%rsp)
      	movl	8(%rsp), %edx
      	addl	4(%rsp), %edx    ## Folded load
      	addl	(%rsp), %edx     ## Folded load
      	movl	%edx, %eax
      	addq	$12, %rsp
      	ret
      
      Fewer instructions and less register use = faster compiles.
      
      llvm-svn: 113102
      eeba0c73
  3. Jul 09, 2010
  4. Apr 15, 2010
  5. Oct 18, 2009
    • Evan Cheng's avatar
      -Revert parts of 84326 and 84411. Distinquishing between fixed and non-fixed · 0e9d9ca8
      Evan Cheng authored
      stack slots and giving them different PseudoSourceValue's did not fix the
      problem of post-alloc scheduling miscompiling llvm itself.
      - Apply Dan's conservative workaround by assuming any non fixed stack slots can
      alias other memory locations. This means a load from spill slot #1 cannot 
      move above a store of spill slot #2. 
      - Enable post-alloc scheduling for x86 at optimization leverl Default and above.
      
      llvm-svn: 84424
      0e9d9ca8
  6. Oct 17, 2009
  7. Sep 25, 2009
    • Dan Gohman's avatar
      Improve MachineMemOperand handling. · 48b185d6
      Dan Gohman authored
       - Allocate MachineMemOperands and MachineMemOperand lists in MachineFunctions.
         This eliminates MachineInstr's std::list member and allows the data to be
         created by isel and live for the remainder of codegen, avoiding a lot of
         copying and unnecessary translation. This also shrinks MemSDNode.
       - Delete MemOperandSDNode. Introduce MachineSDNode which has dedicated
         fields for MachineMemOperands.
       - Change MemSDNode to have a MachineMemOperand member instead of its own
         fields with the same information. This introduces some redundancy, but
         it's more consistent with what MachineInstr will eventually want.
       - Ignore alignment when searching for redundant loads for CSE, but remember
         the greatest alignment.
      
      Target-specific code which previously used MemOperandSDNodes with generic
      SDNodes now use MemIntrinsicSDNodes, with opcodes in a designated range
      so that the SelectionDAG framework knows that MachineMemOperand information
      is available.
      
      llvm-svn: 82794
      48b185d6
  8. Sep 21, 2009
  9. Sep 15, 2009
  10. Jul 16, 2009
  11. Jul 01, 2009
  12. Jun 27, 2009
  13. May 13, 2009
    • Bill Wendling's avatar
      Change MachineInstrBuilder::addReg() to take a flag instead of a list of · f7b83c7a
      Bill Wendling authored
      booleans. This gives a better indication of what the "addReg()" is
      doing. Remembering what all of those booleans mean isn't easy, especially if you
      aren't spending all of your time in that code.
      
      I took Jakob's suggestion and made it illegal to pass in "true" for the
      flag. This should hopefully prevent any unintended misuse of this (by reverting
      to the old way of using addReg()).
      
      llvm-svn: 71722
      f7b83c7a
  14. Apr 08, 2009
    • Rafael Espindola's avatar
      Re-apply 68552. · 3b2df10c
      Rafael Espindola authored
      Tested by bootstrapping llvm-gcc and using that to build llvm.
      
      llvm-svn: 68645
      3b2df10c
    • Bill Wendling's avatar
      Temporarily revert r68552. This was causing a failure in the self-hosting LLVM · 4aa25b79
      Bill Wendling authored
      builds.
      
      --- Reverse-merging (from foreign repository) r68552 into '.':
      U    test/CodeGen/X86/tls8.ll
      U    test/CodeGen/X86/tls10.ll
      U    test/CodeGen/X86/tls2.ll
      U    test/CodeGen/X86/tls6.ll
      U    lib/Target/X86/X86Instr64bit.td
      U    lib/Target/X86/X86InstrSSE.td
      U    lib/Target/X86/X86InstrInfo.td
      U    lib/Target/X86/X86RegisterInfo.cpp
      U    lib/Target/X86/X86ISelLowering.cpp
      U    lib/Target/X86/X86CodeEmitter.cpp
      U    lib/Target/X86/X86FastISel.cpp
      U    lib/Target/X86/X86InstrInfo.h
      U    lib/Target/X86/X86ISelDAGToDAG.cpp
      U    lib/Target/X86/AsmPrinter/X86ATTAsmPrinter.cpp
      U    lib/Target/X86/AsmPrinter/X86IntelAsmPrinter.cpp
      U    lib/Target/X86/AsmPrinter/X86ATTAsmPrinter.h
      U    lib/Target/X86/AsmPrinter/X86IntelAsmPrinter.h
      U    lib/Target/X86/X86ISelLowering.h
      U    lib/Target/X86/X86InstrInfo.cpp
      U    lib/Target/X86/X86InstrBuilder.h
      U    lib/Target/X86/X86RegisterInfo.td
      
      llvm-svn: 68560
      4aa25b79
  15. Apr 07, 2009
  16. Dec 03, 2008
  17. Sep 30, 2008
  18. Sep 06, 2008
  19. Jul 03, 2008
    • Evan Cheng's avatar
      - Remove calls to copyKillDeadInfo which is an N^2 function. Instead,... · 7d98a48f
      Evan Cheng authored
      - Remove calls to copyKillDeadInfo which is an N^2 function. Instead, propagate kill / dead markers as new instructions are constructed in foldMemoryOperand, convertToThressAddress, etc.
      - Also remove LiveVariables::instructionChanged, etc. Replace all calls with cheaper calls which update VarInfo kill list.
      
      llvm-svn: 53097
      7d98a48f
  20. Dec 29, 2007
  21. May 24, 2006
  22. May 04, 2006
  23. Apr 22, 2005
  24. Jan 18, 2005
  25. Jan 02, 2005
  26. Dec 17, 2004
  27. Oct 15, 2004
  28. Aug 30, 2004
  29. Mar 04, 2004
  30. Feb 25, 2004
  31. Nov 11, 2003
  32. Oct 22, 2003
  33. Oct 21, 2003
Loading