[LLVMbugs] [Bug 15487] New: clang emits unnecessary vinsertf128 and vextractf128

bugzilla-daemon at llvm.org bugzilla-daemon at llvm.org
Mon Mar 11 07:34:09 PDT 2013


http://llvm.org/bugs/show_bug.cgi?id=15487

            Bug ID: 15487
           Summary: clang emits unnecessary vinsertf128 and vextractf128
           Product: clang
           Version: trunk
          Hardware: PC
                OS: Linux
            Status: NEW
          Keywords: quality-of-implementation
          Severity: enhancement
          Priority: P
         Component: -New Bugs
          Assignee: unassignedclangbugs at nondot.org
          Reporter: kretz at kde.org
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified

Compile the following testcase with "clang++ -O3 -mavx -c":
#include <immintrin.h>

static inline __m256i __attribute__((always_inline)) my_add(__m256i a0, __m256i
b0)
{
    __m128i a1 = _mm256_extractf128_si256(a0, 1);
    __m128i b1 = _mm256_extractf128_si256(b0, 1);
    __m256i r  =
_mm256_castsi128_si256(_mm_add_epi32(_mm256_castsi256_si128(a0),
_mm256_castsi256_si128(b0)));
    r = _mm256_insertf128_si256(r, _mm_add_epi32(a1, b1), 1);
    return r;
}

extern int DATA[];

void use_insert_extract()
{
    __m256i x = _mm256_loadu_si256((__m256i*)&DATA[0]);
    __m256i y = _mm256_loadu_si256((__m256i*)&DATA[1]);
    x = my_add(x, y);
    x = my_add(x, y);
    _mm256_storeu_si256((__m256i*)&DATA[0], x);
}

Notice the following missing optimizations:
1. clang issues a vmovups + vinsertf128 for the two unaligned-load intrinsics.
Seeing the following vextractf128 it could optimze it though. I.e. this is what
I currently get:
vmovups 0x0(%rip),%xmm0                 # DATA
vinsertf128 $0x1,0x0(%rip),%ymm0,%ymm1  # DATA+0xf
vextractf128 $0x1,%ymm1,%xmm1

instead clang could optimize to:
vmovups 0x0(%rip),%xmm0        # DATA
vmovups 0x0(%rip),%ymm1        # DATA+0xf

2. clang issues two unnecessary vinsertf128 which result from the construction
of the r variable in my_add. The compiler already recognizes that the
vextractf128 in this case can be skipped, but the vinsertf128 is still kept.
I.e. this is what I currently get:
vpaddd %xmm1,%xmm3,%xmm3
vpaddd %xmm1,%xmm3,%xmm1
vpaddd %xmm0,%xmm2,%xmm4
vxorps %xmm2,%xmm2,%xmm2          
vinsertf128 $0x0,%xmm4,%ymm2,%ymm4
vinsertf128 $0x1,%xmm3,%ymm4,%ymm3
vpaddd %xmm0,%xmm3,%xmm0          
vinsertf128 $0x0,%xmm0,%ymm2,%ymm0
vinsertf128 $0x1,%xmm1,%ymm0,%ymm0

instead clang could optimize this to:
vpaddd %xmm1,%xmm3,%xmm3
vpaddd %xmm1,%xmm3,%xmm1
vpaddd %xmm0,%xmm2,%xmm2
vpaddd %xmm0,%xmm2,%xmm0          
vinsertf128 $0x1,%xmm1,%ymm0,%ymm0

-- 
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/20130311/f8829d34/attachment.html>


More information about the llvm-bugs mailing list