1. 28 Aug, 2012 1 commit
  2. 26 Aug, 2012 1 commit
    • Loren Merritt's avatar
      vf_hqdn3d: x86 asm · 7a1944b9
      Loren Merritt authored
      13% faster on penryn, 16% on sandybridge, 15% on bulldozer
      Not simd; a compiler should have generated this, but gcc didn't.
      7a1944b9
  3. 24 Aug, 2012 2 commits
  4. 22 Aug, 2012 1 commit
    • Mans Rullgard's avatar
      x86: remove FASTDIV inline asm · 5b170c0b
      Mans Rullgard authored
      GCC 4.3 and later do the right thing with the plain C code.  Earlier
      versions in 32-bit mode generate one extra instruction, needlessly
      zeroing what would be the high half of the shifted value.  At least
      two gcc configurations miscompile the inline asm in some situations.
      
      In 64-bit mode, all gcc versions generate imul r64, r64 followed by
      shr.  On Intel i7 and later, this imul is faster 32-bit mul.  On
      older Intel and all AMD, it is slightly slower.  On Atom it is much
      slower.
      
      Considering where the FASTDIV macro is used, any overall negative
      performance impact of this change should be negligible.  If anyone
      cares, they should file a bug against gcc and get the instruction
      selection fixed.
      Signed-off-by: 's avatarMans Rullgard <mans@mansr.com>
      5b170c0b
  5. 21 Aug, 2012 1 commit
    • Diego Biurrun's avatar
      configure: Drop fastdiv option · 66baa458
      Diego Biurrun authored
      There is no point in having the user disable any fastdiv macros.
      Besides the condition implementation was broken and only disabled
      the C implementation, but no platform specific assembly versions.
      66baa458
  6. 16 Aug, 2012 3 commits
  7. 15 Aug, 2012 2 commits
  8. 13 Aug, 2012 2 commits
  9. 12 Aug, 2012 1 commit
  10. 10 Aug, 2012 4 commits
  11. 09 Aug, 2012 4 commits
  12. 08 Aug, 2012 6 commits
  13. 07 Aug, 2012 6 commits
  14. 05 Aug, 2012 1 commit
  15. 03 Aug, 2012 2 commits
    • Diego Biurrun's avatar
      x86: build: replace mmx2 by mmxext · 239fdf1b
      Diego Biurrun authored
      Refactoring mmx2/mmxext YASM code with cpuflags will force renames.
      So switching to a consistent naming scheme beforehand is sensible.
      The name "mmxext" is more official and widespread and also the name
      of the CPU flag, as reported e.g. by the Linux kernel.
      239fdf1b
    • Diego Biurrun's avatar
      x86: Use consistent 3dnowext function and macro name suffixes · ca844b7b
      Diego Biurrun authored
      Currently there is a wild mix of 3dn2/3dnow2/3dnowext.  Switching to
      "3dnowext", which is a more common name of the CPU flag, as reported
      e.g. by the Linux kernel, unifies this.
      ca844b7b
  16. 01 Aug, 2012 1 commit
  17. 31 Jul, 2012 1 commit
  18. 30 Jul, 2012 1 commit