Skip to content
  1. Jul 08, 2009
  2. Jul 07, 2009
  3. Jul 03, 2009
    • Tilmann Scheller's avatar
      Add NumFixedArgs attribute to CallSDNode which indicates the number of fixed... · aea6059e
      Tilmann Scheller authored
      Add NumFixedArgs attribute to CallSDNode which indicates the number of fixed arguments in a vararg call.
      
      With the SVR4 ABI on PowerPC, vector arguments for vararg calls are passed differently depending on whether they are a fixed or a variable argument. Variable vector arguments always go into memory, fixed vector arguments are put 
      into vector registers. If there are no free vector registers available, fixed vector arguments are put on the stack.
      
      The NumFixedArgs attribute allows to decide for an argument in a vararg call whether it belongs to the fixed or variable portion of the parameter list.
      
      llvm-svn: 74764
      aea6059e
  4. Jul 01, 2009
  5. Jun 30, 2009
    • David Greene's avatar
      · 8adf1fdc
      David Greene authored
      Add a 256-bit register class and YMM registers.
      
      llvm-svn: 74469
      8adf1fdc
  6. Jun 29, 2009
    • Owen Anderson's avatar
      Add a target-specific DAG combine on X86 to fold the common pattern of · 45c299ef
      Owen Anderson authored
      fence-atomic-fence down to just the atomic op.  This is possible thanks to
      X86's relatively strong memory model, which guarantees that locked instructions
      (which are used to implement atomics) are implicit fences.
      
      llvm-svn: 74435
      45c299ef
    • David Greene's avatar
      · f92ba97c
      David Greene authored
      Add more vector ValueTypes for AVX and other extended vector instruction
      sets.
      
      llvm-svn: 74427
      f92ba97c
  7. Jun 27, 2009
    • Chris Lattner's avatar
      ae0acfce
    • Chris Lattner's avatar
      Reimplement rip-relative addressing in the X86-64 backend. The new · fea81da4
      Chris Lattner authored
      implementation primarily differs from the former in that the asmprinter
      doesn't make a zillion decisions about whether or not something will be
      RIP relative or not.  Instead, those decisions are made by isel lowering
      and propagated through to the asm printer.  To achieve this, we:
      
      1. Represent RIP relative addresses by setting the base of the X86 addr
         mode to X86::RIP.
      2. When ISel Lowering decides that it is safe to use RIP, it lowers to
         X86ISD::WrapperRIP.  When it is unsafe to use RIP, it lowers to
         X86ISD::Wrapper as before.
      3. This removes isRIPRel from X86ISelAddressMode, representing it with
         a basereg of RIP instead.
      4. The addressing mode matching logic in isel is greatly simplified.
      5. The asmprinter is greatly simplified, notably the "NotRIPRel" predicate
         passed through various printoperand routines is gone now.
      6. The various symbol printing routines in asmprinter now no longer infer
         when to emit (%rip), they just print the symbol.
      
      I think this is a big improvement over the previous situation.  It does have
      two small caveats though: 1. I implemented a horrible "no-rip" modifier for
      the inline asm "P" constraint modifier.  This is a short term hack, there is
      a much better, but more involved, solution.  2. I had to xfail an 
      -aggressive-remat testcase because it isn't handling the use of RIP in the
      constant-pool reading instruction.  This specific test is easy to fix without
      -aggressive-remat, which I intend to do next.
      
      llvm-svn: 74372
      fea81da4
  8. Jun 26, 2009
  9. Jun 21, 2009
  10. Jun 16, 2009
  11. Jun 15, 2009
  12. Jun 12, 2009
    • Arnold Schwaighofer's avatar
      Fix Bug 4278: X86-64 with -tailcallopt calling convention · e3a018d7
      Arnold Schwaighofer authored
      out of sync with regular cc.
      
      The only difference between the tail call cc and the normal
      cc was that one parameter register - R9 - was reserved for
      calling functions through a function pointer. After time the
      tail call cc has gotten out of sync with the regular cc. 
      
      We can use R11 which is also caller saved but not used as
      parameter register for potential function pointers and
      remove the special tail call cc on x86-64.
      
      llvm-svn: 73233
      e3a018d7
  13. Jun 10, 2009
  14. Jun 07, 2009
  15. Jun 06, 2009
  16. Jun 05, 2009
    • Devang Patel's avatar
      Add new function attribute - noimplicitfloat · d1c7d349
      Devang Patel authored
      Update code generator to use this attribute and remove NoImplicitFloat target option.
      Update llc to set this attribute when -no-implicit-float command line option is used.
      
      llvm-svn: 72959
      d1c7d349
    • Nate Begeman's avatar
      Adapt the x86 build_vector dagcombine to the current state of the legalizer. · 624690c6
      Nate Begeman authored
      build vectors with i64 elements will only appear on 32b x86 before legalize.
      Since vector widening occurs during legalize, and produces i64 build_vector 
      elements, the dag combiner is never run on these before legalize splits them
      into 32b elements.
      
      Teach the build_vector dag combine in x86 back end to recognize consecutive 
      loads producing the low part of the vector.
      
      Convert the two uses of TLI's consecutive load recognizer to pass LoadSDNodes
      since that was required implicitly.
      
      Add a testcase for the transform.
      
      Old:
      	subl	$28, %esp
      	movl	32(%esp), %eax
      	movl	4(%eax), %ecx
      	movl	%ecx, 4(%esp)
      	movl	(%eax), %eax
      	movl	%eax, (%esp)
      	movaps	(%esp), %xmm0
      	pmovzxwd	%xmm0, %xmm0
      	movl	36(%esp), %eax
      	movaps	%xmm0, (%eax)
      	addl	$28, %esp
      	ret
      
      New:
      	movl	4(%esp), %eax
      	pmovzxwd	(%eax), %xmm0
      	movl	8(%esp), %eax
      	movaps	%xmm0, (%eax)
      	ret
      
      llvm-svn: 72957
      624690c6
    • Devang Patel's avatar
      Evan thinks NoImplicitFloat check is not required here. · 54707b42
      Devang Patel authored
      llvm-svn: 72954
      54707b42
  17. Jun 03, 2009
  18. Jun 02, 2009
    • Dale Johannesen's avatar
      Revert 72707 and 72709, for the moment. · 5234d379
      Dale Johannesen authored
      llvm-svn: 72712
      5234d379
    • Dale Johannesen's avatar
      Make the implicit inputs and outputs of target-independent · 0b8ca792
      Dale Johannesen authored
      ADDC/ADDE use MVT::i1 (later, whatever it gets legalized to)
      instead of MVT::Flag.  Remove CARRY_FALSE in favor of 0; adjust
      all target-independent code to use this format.
      
      Most targets will still produce a Flag-setting target-dependent
      version when selection is done.  X86 is converted to use i32
      instead, which means TableGen needs to produce different code
      in xxxGenDAGISel.inc.  This keys off the new supportsHasI1 bit
      in xxxInstrInfo, currently set only for X86; in principle this
      is temporary and should go away when all other targets have
      been converted.  All relevant X86 instruction patterns are
      modified to represent setting and using EFLAGS explicitly.  The
      same can be done on other targets.
      
      The immediate behavior change is that an ADC/ADD pair are no
      longer tightly coupled in the X86 scheduler; they can be
      separated by instructions that don't clobber the flags (MOV).
      I will soon add some peephole optimizations based on using
      other instructions that set the flags to feed into ADC.
      
      llvm-svn: 72707
      0b8ca792
  19. May 30, 2009
  20. May 28, 2009
    • Evan Cheng's avatar
      Added optimization that narrow load / op / store and the 'op' is a bit... · a9cda8ab
      Evan Cheng authored
      Added optimization that narrow load / op / store and the 'op' is a bit twiddling instruction and its second operand is an immediate. If bits that are touched by 'op' can be done with a narrower instruction, reduce the width of the load and store as well. This happens a lot with bitfield manipulation code.
      e.g.
      orl     $65536, 8(%rax)
      =>
      orb     $1, 10(%rax)
      
      Since narrowing is not always a win, e.g. i32 -> i16 is a loss on x86, dag combiner consults with the target before performing the optimization.
      
      llvm-svn: 72507
      a9cda8ab
  21. May 27, 2009
  22. May 26, 2009
  23. May 24, 2009
  24. May 23, 2009
    • Eli Friedman's avatar
      Make the x86 backend custom-lower UINT_TO_FP and FP_TO_UINT on 32-bit · dfe4f253
      Eli Friedman authored
      systems instead of attempting to promote them to a 64-bit SINT_TO_FP or 
      FP_TO_SINT.  This is in preparation for removing the type legalization 
      code from LegalizeDAG: once type legalization is gone from LegalizeDAG, 
      it won't be able to handle the i64 operand/result correctly.
      
      This isn't quite ideal, but I don't think any other operation for any 
      target ends up in this situation, so treating this case specially seems 
      reasonable.
      
      llvm-svn: 72324
      dfe4f253
  25. May 13, 2009
Loading