[llvm-bugs] [Bug 41496] New: _mm_avg_epu16 and _mm_avg_epu8 still broken...

[via llvm-bugs]

https://bugs.llvm.org/show_bug.cgi?id=41496

            Bug ID: 41496
           Summary: _mm_avg_epu16 and _mm_avg_epu8 still broken...
           Product: libraries
           Version: 8.0
          Hardware: PC
                OS: Linux
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: Backend: X86
          Assignee: unassignedbugs at nondot.org
          Reporter: jeffr at radgametools.com
                CC: craig.topper at gmail.com, llvm-bugs at lists.llvm.org,
                    llvm-dev at redking.me.uk, spatel+llvm at rotateright.com

This is a continuation of bug 41316, where we reported that a shift instruction
before mm_avg intrinsics caused terrible code to be generated. Simon fixed this
exact problem, but there are still lots of ways to trigger the terrible
behavior.

For example, try this on clang 5 vs 6 (or anything since, including the current
trunk):

int test(__m128i a, __m128i b)
{
  __m128i c;
  c = _mm_avg_epu8(a, b);
  c = _mm_avg_epu8(c, b);
  return _mm_cvtsi128_si32(c);
}

But it doesn't just trigger with two averages - on real routines, it fails with
other arithmetic instructions that fold into the avg (both 8 and 16) as well.

P.S. Just a data point as a heavy, heavy intrinsics-using company: we don't
want *ANY* of this.  I get that you want this stuff for autovec, but when we
write intrinsics, we want *those* intrinsics.  It would be nice if you flagged
intentional intrinsics and leave them alone.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20190414/98c84d18/attachment.html>