Skip to content
  1. May 28, 2009
    • Bill Wendling's avatar
      "The instructions MMX_PSADBWrm and MMX_PSADBWrr have opcode 0b11100000 (e0), but · 0feb0e60
      Bill Wendling authored
      the Intel manual (screenshot) says it should be 0b11110110 (f6).  The existing
      encoding causes a disassembly conflict with MMX_PAVGBrm, which really should be
      0f e0."
      
      Patch by Sean Callanan!
      
      llvm-svn: 72508
      0feb0e60
    • 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
  2. May 27, 2009
  3. May 26, 2009
  4. May 25, 2009
  5. May 24, 2009
  6. May 23, 2009
  7. May 20, 2009
  8. May 18, 2009
  9. May 15, 2009
  10. May 13, 2009
  11. May 12, 2009
  12. May 11, 2009
  13. May 09, 2009
  14. May 08, 2009
  15. May 06, 2009
    • Dale Johannesen's avatar
      Use X86AddrNumOperands instead of magic constant one · 72b6582c
      Dale Johannesen authored
      more place.  This fixes a bunch of x86-64 JIT regressions.
      (Introduced when the value of the magic constant changed
      in 68645.  At the time apparently nobody noticed; failures
      were hidden in 70343-70439 by an unrelated bug, so showed
      up again as "new" failures in 70440.)
      
      llvm-svn: 71106
      72b6582c
  16. May 05, 2009
  17. May 04, 2009
  18. May 01, 2009
  19. Apr 30, 2009
Loading