Skip to content
  1. Apr 03, 2013
    • Jakob Stoklund Olesen's avatar
      Add 64-bit compare + branch for SPARC v9. · d9bbdfd3
      Jakob Stoklund Olesen authored
      The same compare instruction is used for 32-bit and 64-bit compares. It
      sets two different sets of flags: icc and xcc.
      
      This patch adds a conditional branch instruction using the xcc flags for
      64-bit compares.
      
      llvm-svn: 178621
      d9bbdfd3
  2. Apr 02, 2013
    • Jakob Stoklund Olesen's avatar
      Add 64-bit load and store instructions. · 8eabc3ff
      Jakob Stoklund Olesen authored
      There is only a few new instructions, the rest is handled with patterns.
      
      llvm-svn: 178528
      8eabc3ff
    • Jakob Stoklund Olesen's avatar
      Basic 64-bit ALU operations. · 917e07f0
      Jakob Stoklund Olesen authored
      SPARC v9 extends all ALU instructions to 64 bits, so we simply need to
      add patterns to use them for both i32 and i64 values.
      
      llvm-svn: 178527
      917e07f0
    • Jakob Stoklund Olesen's avatar
      Materialize 64-bit immediates. · bddb20ee
      Jakob Stoklund Olesen authored
      The last resort pattern produces 6 instructions, and there are still
      opportunities for materializing some immediates in fewer instructions.
      
      llvm-svn: 178526
      bddb20ee
    • Jakob Stoklund Olesen's avatar
      Add 64-bit shift instructions. · c1d1a481
      Jakob Stoklund Olesen authored
      SPARC v9 defines new 64-bit shift instructions. The 32-bit shift right
      instructions are still usable as zero and sign extensions.
      
      This adds new F3_Sr and F3_Si instruction formats that probably should
      be used for the 32-bit shifts as well. They don't really encode an
      simm13 field.
      
      llvm-svn: 178525
      c1d1a481
    • Jakob Stoklund Olesen's avatar
      Add predicates for distinguishing 32-bit and 64-bit modes. · 739d722e
      Jakob Stoklund Olesen authored
      The 'sparc' architecture produces 32-bit code while 'sparcv9' produces
      64-bit code.
      
      It is also possible to run 32-bit code using SPARC v9 instructions with:
      
        llc -march=sparc -mattr=+v9
      
      llvm-svn: 178524
      739d722e
    • Jakob Stoklund Olesen's avatar
      Add support for 64-bit calling convention. · 0b21f35a
      Jakob Stoklund Olesen authored
      This is far from complete, but it is enough to make it possible to write
      test cases using i64 arguments.
      
      Missing features:
      - Floating point arguments.
      - Receiving arguments on the stack.
      - Calls.
      
      llvm-svn: 178523
      0b21f35a
    • Jakob Stoklund Olesen's avatar
      Add an I64Regs register class for 64-bit registers. · 5ad3b353
      Jakob Stoklund Olesen authored
      We are going to use the same registers for 32-bit and 64-bit values, but
      in two different register classes. The I64Regs register class has a
      larger spill size and alignment.
      
      The addition of an i64 register class confuses TableGen's type
      inference, so it is necessary to clarify the type of some immediates and
      the G0 register.
      
      In 64-bit mode, pointers are i64 and should use the I64Regs register
      class. Implement getPointerRegClass() to dynamically provide the pointer
      register class depending on the subtarget. Use ptr_rc and iPTR for
      memory operands.
      
      Finally, add the i64 type to the IntRegs register class. This register
      class is not used to hold i64 values, I64Regs is for that. The type is
      required to appease TableGen's type checking in output patterns like this:
      
        def : Pat<(add i64:$a, i64:$b), (ADDrr $a, $b)>;
      
      SPARC v9 uses the same ADDrr instruction for i32 and i64 additions, and
      TableGen doesn't know to check the type of register sub-classes.
      
      llvm-svn: 178522
      5ad3b353
  3. Mar 24, 2013
  4. Mar 23, 2013
  5. Mar 14, 2013
    • Hal Finkel's avatar
      Provide the register scavenger to processFunctionBeforeFrameFinalized · 5a765fdd
      Hal Finkel authored
      Add the current PEI register scavenger as a parameter to the
      processFunctionBeforeFrameFinalized callback.
      
      This change is necessary in order to allow the PowerPC target code to
      set the register scavenger frame index after the save-area offset
      adjustments performed by processFunctionBeforeFrameFinalized. Only
      after these adjustments have been made is it possible to estimate
      the size of the stack frame.
      
      llvm-svn: 177108
      5a765fdd
  6. Mar 07, 2013
  7. Feb 21, 2013
    • Eli Bendersky's avatar
      Move the eliminateCallFramePseudoInstr method from TargetRegisterInfo · 8da87163
      Eli Bendersky authored
      to TargetFrameLowering, where it belongs. Incidentally, this allows us
      to delete some duplicated (and slightly different!) code in TRI.
      
      There are potentially other layering problems that can be cleaned up
      as a result, or in a similar manner.
      
      The refactoring was OK'd by Anton Korobeynikov on llvmdev.
      
      Note: this touches the target interfaces, so out-of-tree targets may
      be affected.
      
      llvm-svn: 175788
      8da87163
  8. Feb 05, 2013
  9. Jan 31, 2013
  10. Jan 29, 2013
    • Evan Cheng's avatar
      Teach SDISel to combine fsin / fcos into a fsincos node if the following · 0e88c7d8
      Evan Cheng authored
      conditions are met:
      1. They share the same operand and are in the same BB.
      2. Both outputs are used.
      3. The target has a native instruction that maps to ISD::FSINCOS node or
         the target provides a sincos library call.
      
      Implemented the generic optimization in sdisel and enabled it for
      Mac OSX. Also added an additional optimization for x86_64 Mac OSX by
      using an alternative entry point __sincos_stret which returns the two
      results in xmm0 / xmm1.
      
      rdar://13087969
      PR13204
      
      llvm-svn: 173755
      0e88c7d8
  11. Jan 23, 2013
  12. Jan 07, 2013
    • Chandler Carruth's avatar
      Switch TargetTransformInfo from an immutable analysis pass that requires · 664e354d
      Chandler Carruth authored
      a TargetMachine to construct (and thus isn't always available), to an
      analysis group that supports layered implementations much like
      AliasAnalysis does. This is a pretty massive change, with a few parts
      that I was unable to easily separate (sorry), so I'll walk through it.
      
      The first step of this conversion was to make TargetTransformInfo an
      analysis group, and to sink the nonce implementations in
      ScalarTargetTransformInfo and VectorTargetTranformInfo into
      a NoTargetTransformInfo pass. This allows other passes to add a hard
      requirement on TTI, and assume they will always get at least on
      implementation.
      
      The TargetTransformInfo analysis group leverages the delegation chaining
      trick that AliasAnalysis uses, where the base class for the analysis
      group delegates to the previous analysis *pass*, allowing all but tho
      NoFoo analysis passes to only implement the parts of the interfaces they
      support. It also introduces a new trick where each pass in the group
      retains a pointer to the top-most pass that has been initialized. This
      allows passes to implement one API in terms of another API and benefit
      when some other pass above them in the stack has more precise results
      for the second API.
      
      The second step of this conversion is to create a pass that implements
      the TargetTransformInfo analysis using the target-independent
      abstractions in the code generator. This replaces the
      ScalarTargetTransformImpl and VectorTargetTransformImpl classes in
      lib/Target with a single pass in lib/CodeGen called
      BasicTargetTransformInfo. This class actually provides most of the TTI
      functionality, basing it upon the TargetLowering abstraction and other
      information in the target independent code generator.
      
      The third step of the conversion adds support to all TargetMachines to
      register custom analysis passes. This allows building those passes with
      access to TargetLowering or other target-specific classes, and it also
      allows each target to customize the set of analysis passes desired in
      the pass manager. The baseline LLVMTargetMachine implements this
      interface to add the BasicTTI pass to the pass manager, and all of the
      tools that want to support target-aware TTI passes call this routine on
      whatever target machine they end up with to add the appropriate passes.
      
      The fourth step of the conversion created target-specific TTI analysis
      passes for the X86 and ARM backends. These passes contain the custom
      logic that was previously in their extensions of the
      ScalarTargetTransformInfo and VectorTargetTransformInfo interfaces.
      I separated them into their own file, as now all of the interface bits
      are private and they just expose a function to create the pass itself.
      Then I extended these target machines to set up a custom set of analysis
      passes, first adding BasicTTI as a fallback, and then adding their
      customized TTI implementations.
      
      The fourth step required logic that was shared between the target
      independent layer and the specific targets to move to a different
      interface, as they no longer derive from each other. As a consequence,
      a helper functions were added to TargetLowering representing the common
      logic needed both in the target implementation and the codegen
      implementation of the TTI pass. While technically this is the only
      change that could have been committed separately, it would have been
      a nightmare to extract.
      
      The final step of the conversion was just to delete all the old
      boilerplate. This got rid of the ScalarTargetTransformInfo and
      VectorTargetTransformInfo classes, all of the support in all of the
      targets for producing instances of them, and all of the support in the
      tools for manually constructing a pass based around them.
      
      Now that TTI is a relatively normal analysis group, two things become
      straightforward. First, we can sink it into lib/Analysis which is a more
      natural layer for it to live. Second, clients of this interface can
      depend on it *always* being available which will simplify their code and
      behavior. These (and other) simplifications will follow in subsequent
      commits, this one is clearly big enough.
      
      Finally, I'm very aware that much of the comments and documentation
      needs to be updated. As soon as I had this working, and plausibly well
      commented, I wanted to get it committed and in front of the build bots.
      I'll be doing a few passes over documentation later if it sticks.
      
      Commits to update DragonEgg and Clang will be made presently.
      
      llvm-svn: 171681
      664e354d
  13. Jan 02, 2013
    • Chandler Carruth's avatar
      Move all of the header files which are involved in modelling the LLVM IR · 9fb823bb
      Chandler Carruth authored
      into their new header subdirectory: include/llvm/IR. This matches the
      directory structure of lib, and begins to correct a long standing point
      of file layout clutter in LLVM.
      
      There are still more header files to move here, but I wanted to handle
      them in separate commits to make tracking what files make sense at each
      layer easier.
      
      The only really questionable files here are the target intrinsic
      tablegen files. But that's a battle I'd rather not fight today.
      
      I've updated both CMake and Makefile build systems (I think, and my
      tests think, but I may have missed something).
      
      I've also re-sorted the includes throughout the project. I'll be
      committing updates to Clang, DragonEgg, and Polly momentarily.
      
      llvm-svn: 171366
      9fb823bb
  14. Dec 04, 2012
  15. Dec 03, 2012
    • Chandler Carruth's avatar
      Use the new script to sort the includes of every file under lib. · ed0881b2
      Chandler Carruth authored
      Sooooo many of these had incorrect or strange main module includes.
      I have manually inspected all of these, and fixed the main module
      include to be the nearest plausible thing I could find. If you own or
      care about any of these source files, I encourage you to take some time
      and check that these edits were sensible. I can't have broken anything
      (I strictly added headers, and reordered them, never removed), but they
      may not be the headers you'd really like to identify as containing the
      API being implemented.
      
      Many forward declarations and missing includes were added to a header
      files to allow them to parse cleanly when included first. The main
      module rule does in fact have its merits. =]
      
      llvm-svn: 169131
      ed0881b2
  16. Oct 24, 2012
  17. Oct 19, 2012
  18. Oct 18, 2012
    • Bob Wilson's avatar
      Temporarily revert the TargetTransform changes. · d6d9ccca
      Bob Wilson authored
      The TargetTransform changes are breaking LTO bootstraps of clang.  I am
      working with Nadav to figure out the problem, but I am reverting it for now
      to get our buildbots working.
      
      This reverts svn commits: 165665 165669 165670 165786 165787 165997
      and I have also reverted clang svn 165741
      
      llvm-svn: 166168
      d6d9ccca
  19. Oct 11, 2012
    • Nadav Rotem's avatar
      · e1032873
      Nadav Rotem authored
      Add a new interface to allow IR-level passes to access codegen-specific information.
      
      llvm-svn: 165665
      e1032873
  20. Oct 08, 2012
  21. Aug 24, 2012
  22. Aug 06, 2012
  23. Jul 19, 2012
  24. Jul 02, 2012
  25. Jun 26, 2012
    • Jack Carter's avatar
      There are a number of generic inline asm operand modifiers that · 5e69cffe
      Jack Carter authored
      up to r158925 were handled as processor specific. Making them 
      generic and putting tests for these modifiers in the CodeGen/Generic
      directory caused a number of targets to fail. 
      
      This commit addresses that problem by having the targets call 
      the generic routine for generic modifiers that they don't currently
      have explicit code for.
      
      For now only generic print operands 'c' and 'n' are supported.vi
      
      
      Affected files:
      
          test/CodeGen/Generic/asm-large-immediate.ll
          lib/Target/PowerPC/PPCAsmPrinter.cpp
          lib/Target/NVPTX/NVPTXAsmPrinter.cpp
          lib/Target/ARM/ARMAsmPrinter.cpp
          lib/Target/XCore/XCoreAsmPrinter.cpp
          lib/Target/X86/X86AsmPrinter.cpp
          lib/Target/Hexagon/HexagonAsmPrinter.cpp
          lib/Target/CellSPU/SPUAsmPrinter.cpp
          lib/Target/Sparc/SparcAsmPrinter.cpp
          lib/Target/MBlaze/MBlazeAsmPrinter.cpp
          lib/Target/Mips/MipsAsmPrinter.cpp
          
      MSP430 isn't represented because it did not even run with
      the long existing 'c' modifier and it was not apparent what
      needs to be done to get it inline asm ready.
      
      Contributer: Jack Carter
      llvm-svn: 159203
      5e69cffe
  26. Jun 24, 2012
  27. Jun 06, 2012
  28. Jun 01, 2012
  29. May 25, 2012
  30. May 04, 2012
  31. May 01, 2012
  32. Apr 20, 2012
  33. Apr 04, 2012
    • Rafael Espindola's avatar
      Always compute all the bits in ComputeMaskedBits. · ba0a6cab
      Rafael Espindola authored
      This allows us to keep passing reduced masks to SimplifyDemandedBits, but
      know about all the bits if SimplifyDemandedBits fails. This allows instcombine
      to simplify cases like the one in the included testcase.
      
      llvm-svn: 154011
      ba0a6cab
Loading