Skip to content
  1. Jun 25, 2011
  2. Jun 24, 2011
    • Evan Cheng's avatar
      Starting to refactor Target to separate out code that's needed to fully describe · 24753317
      Evan Cheng authored
      target machine from those that are only needed by codegen. The goal is to
      sink the essential target description into MC layer so we can start building
      MC based tools without needing to link in the entire codegen.
      
      First step is to refactor TargetRegisterInfo. This patch added a base class
      MCRegisterInfo which TargetRegisterInfo is derived from. Changed TableGen to
      separate register description from the rest of the stuff.
      
      llvm-svn: 133782
      24753317
  3. Dec 20, 2010
  4. Jul 16, 2010
  5. Jul 10, 2010
  6. Apr 06, 2010
    • Jim Grosbach's avatar
      Fix PR6696 and PR6663 · 4dac8906
      Jim Grosbach authored
      When a frame pointer is not otherwise required, and dynamic stack alignment
      is necessary solely due to the spilling of a register with larger alignment
      requirements than the default stack alignment, the frame pointer can be both
      used as a general purpose register and a frame pointer. That goes poorly, for
      obvious reasons. This patch brings back a bit of old logic for identifying
      the use of such registers and conservatively reserves the frame pointer
      during register allocation in such cases.
      
      For now, implement for X86 only since it's 32-bit linux which is hitting this,
      and we want a targeted fix for 2.7. As a follow-on, this will be expanded
      to handle other targets, as theoretically the problem could arise elsewhere
      as well.
      
      llvm-svn: 100559
      4dac8906
  7. Mar 25, 2010
    • Jakob Stoklund Olesen's avatar
      Add a late SSEDomainFix pass that twiddles SSE instructions to avoid domain crossings. · 49e121d5
      Jakob Stoklund Olesen authored
      On Nehalem and newer CPUs there is a 2 cycle latency penalty on using a register
      in a different domain than where it was defined. Some instructions have
      equvivalents for different domains, like por/orps/orpd.
      
      The SSEDomainFix pass tries to minimize the number of domain crossings by
      changing between equvivalent opcodes where possible.
      
      This is a work in progress, in particular the pass doesn't do anything yet. SSE
      instructions are tagged with their execution domain in TableGen using the last
      two bits of TSFlags. Note that not all instructions are tagged correctly. Life
      just isn't that simple.
      
      The SSE execution domain issue is very similar to the ARM NEON/VFP pipeline
      issue handled by NEONMoveFixPass. This pass may become target independent to
      handle both.
      
      llvm-svn: 99524
      49e121d5
  8. Mar 24, 2010
  9. Mar 11, 2010
  10. Feb 21, 2010
  11. Feb 13, 2010
  12. Feb 05, 2010
  13. Feb 03, 2010
  14. Feb 02, 2010
  15. Dec 02, 2009
  16. Aug 27, 2009
    • Daniel Dunbar's avatar
      llvm-mc/X86: Implement single instruction encoding interface for MC. · 981a71c3
      Daniel Dunbar authored
       - Note, this is a gigantic hack, with the sole purpose of unblocking further
         work on the assembler (its also possible to test the mathcer more completely
         now).
      
       - Despite being a hack, its actually good enough to work over all of 403.gcc
         (although some encodings are probably incorrect). This is a testament to the 
         beauty of X86's MachineInstr, no doubt! ;)
      
      llvm-svn: 80234
      981a71c3
  17. Jul 25, 2009
  18. Jul 19, 2009
  19. Jul 15, 2009
    • Daniel Dunbar's avatar
      Reapply TargetRegistry refactoring commits. · e833810a
      Daniel Dunbar authored
      --- Reverse-merging r75799 into '.':
       U   test/Analysis/PointerTracking
      U    include/llvm/Target/TargetMachineRegistry.h
      U    include/llvm/Target/TargetMachine.h
      U    include/llvm/Target/TargetRegistry.h
      U    include/llvm/Target/TargetSelect.h
      U    tools/lto/LTOCodeGenerator.cpp
      U    tools/lto/LTOModule.cpp
      U    tools/llc/llc.cpp
      U    lib/Target/PowerPC/PPCTargetMachine.h
      U    lib/Target/PowerPC/AsmPrinter/PPCAsmPrinter.cpp
      U    lib/Target/PowerPC/PPCTargetMachine.cpp
      U    lib/Target/PowerPC/PPC.h
      U    lib/Target/ARM/ARMTargetMachine.cpp
      U    lib/Target/ARM/AsmPrinter/ARMAsmPrinter.cpp
      U    lib/Target/ARM/ARMTargetMachine.h
      U    lib/Target/ARM/ARM.h
      U    lib/Target/XCore/XCoreTargetMachine.cpp
      U    lib/Target/XCore/XCoreTargetMachine.h
      U    lib/Target/PIC16/PIC16TargetMachine.cpp
      U    lib/Target/PIC16/PIC16TargetMachine.h
      U    lib/Target/Alpha/AsmPrinter/AlphaAsmPrinter.cpp
      U    lib/Target/Alpha/AlphaTargetMachine.cpp
      U    lib/Target/Alpha/AlphaTargetMachine.h
      U    lib/Target/X86/X86TargetMachine.h
      U    lib/Target/X86/X86.h
      U    lib/Target/X86/AsmPrinter/X86ATTAsmPrinter.h
      U    lib/Target/X86/AsmPrinter/X86AsmPrinter.cpp
      U    lib/Target/X86/AsmPrinter/X86IntelAsmPrinter.h
      U    lib/Target/X86/X86TargetMachine.cpp
      U    lib/Target/MSP430/MSP430TargetMachine.cpp
      U    lib/Target/MSP430/MSP430TargetMachine.h
      U    lib/Target/CppBackend/CPPTargetMachine.h
      U    lib/Target/CppBackend/CPPBackend.cpp
      U    lib/Target/CBackend/CTargetMachine.h
      U    lib/Target/CBackend/CBackend.cpp
      U    lib/Target/TargetMachine.cpp
      U    lib/Target/IA64/IA64TargetMachine.cpp
      U    lib/Target/IA64/AsmPrinter/IA64AsmPrinter.cpp
      U    lib/Target/IA64/IA64TargetMachine.h
      U    lib/Target/IA64/IA64.h
      U    lib/Target/MSIL/MSILWriter.cpp
      U    lib/Target/CellSPU/SPUTargetMachine.h
      U    lib/Target/CellSPU/SPU.h
      U    lib/Target/CellSPU/AsmPrinter/SPUAsmPrinter.cpp
      U    lib/Target/CellSPU/SPUTargetMachine.cpp
      U    lib/Target/Mips/AsmPrinter/MipsAsmPrinter.cpp
      U    lib/Target/Mips/MipsTargetMachine.cpp
      U    lib/Target/Mips/MipsTargetMachine.h
      U    lib/Target/Mips/Mips.h
      U    lib/Target/Sparc/AsmPrinter/SparcAsmPrinter.cpp
      U    lib/Target/Sparc/SparcTargetMachine.cpp
      U    lib/Target/Sparc/SparcTargetMachine.h
      U    lib/ExecutionEngine/JIT/TargetSelect.cpp
      U    lib/Support/TargetRegistry.cpp
      
      llvm-svn: 75820
      e833810a
    • Stuart Hastings's avatar
      Revert 75762, 75763, 75766..75769, 75772..75775, 75778, 75780, 75782 to repair... · 338191cd
      Stuart Hastings authored
      Revert 75762, 75763, 75766..75769, 75772..75775, 75778, 75780, 75782 to repair broken LLVM-GCC build.
      Will revert 75770 in the llvm-gcc trunk.
      
      llvm-svn: 75799
      338191cd
    • Daniel Dunbar's avatar
      Register Target's TargetMachine and AsmPrinter in the new registry. · b22f50e4
      Daniel Dunbar authored
       - This abuses TargetMachineRegistry's constructor for now, this will get
         cleaned up in time.
      
      llvm-svn: 75762
      b22f50e4
  20. Jul 14, 2009
    • David Greene's avatar
      · a31f96cf
      David Greene authored
      Have asm printers use formatted_raw_ostream directly to avoid a
      dynamic_cast<>.
      
      llvm-svn: 75670
      a31f96cf
  21. Jul 06, 2009
  22. Jul 01, 2009
  23. Jun 01, 2009
  24. May 30, 2009
  25. Apr 30, 2009
  26. Apr 29, 2009
    • Bill Wendling's avatar
      Second attempt: · 084669a1
      Bill Wendling authored
      Massive check in. This changes the "-fast" flag to "-O#" in llc. If you want to
      use the old behavior, the flag is -O0. This change allows for finer-grained
      control over which optimizations are run at different -O levels.
      
      Most of this work was pretty mechanical. The majority of the fixes came from
      verifying that a "fast" variable wasn't used anymore. The JIT still uses a
      "Fast" flag. I'll change the JIT with a follow-up patch.
      
      llvm-svn: 70343
      084669a1
  27. Apr 28, 2009
  28. Mar 25, 2009
  29. Feb 24, 2009
  30. Jan 05, 2009
  31. Nov 12, 2008
  32. Aug 21, 2008
  33. Apr 23, 2008
Loading