Why gcc is so much worse at std::vector vectorization of a conditional multiply than clang?

It’s not std::vector that’s the problem, it’s float and GCC’s usually-bad default of -ftrapping-math that is supposed to treat FP exceptions as a visible side-effect, but doesn’t always correctly do that, and misses some optimizations that would be safe.

In this case, there is a conditional FP multiply in the source, so strict exception behaviour avoids possibly raising an overflow, underflow, inexact, or other exception in case the compare was false.

GCC does that correctly in this case using scalar code: ...ss is Scalar Single, using the bottom element of 128-bit XMM registers, not vectorized at all. Your asm isn’t GCC’s actual output: it loads both elements with vmovss, then branches on a vcomiss result before vmulss, so the multiply doesn’t happen if b[i] > c[i] isn’t true. So unlike your "GCC" asm, GCC’s actual asm does I think correctly implement -ftrapping-math.

Notice that your example which does auto-vectorize uses int * args, not float*. If you change it to float* and use the same compiler options, it doesn’t auto-vectorize either, even with float *__restrict a (https://godbolt.org/z/nPzsf377b).

@273K’s answer shows that AVX-512 lets float auto-vectorize even with -ftrapping-math, since AVX-512 masking (ymm2{k1}{z}) suppresses FP exceptions for masked elements, not raising FP exceptions from any FP multiplies that don’t happen in the C++ abstract machine.

gcc -O3 -mavx2 -mfma -fno-trapping-math auto-vectorizes all 3 functions (Godbolt)

void foo (float *__restrict a, float *__restrict b, float *__restrict c) {
  for (int i=0; i<256; i++){
    a[i] =  (b[i] > c[i]) ? (b[i] * c[i]) : 0;
  }
}

foo(float*, float*, float*):
        xor     eax, eax
.L143:
        vmovups ymm2, YMMWORD PTR [rsi+rax]
        vmovups ymm3, YMMWORD PTR [rdx+rax]
        vmulps  ymm1, ymm2, YMMWORD PTR [rdx+rax]
        vcmpltps        ymm0, ymm3, ymm2
        vandps  ymm0, ymm0, ymm1
        vmovups YMMWORD PTR [rdi+rax], ymm0
        add     rax, 32
        cmp     rax, 1024
        jne     .L143
        vzeroupper
        ret

BTW, I’d recommend -march=x86-64-v3 for an AVX2+FMA feature-level. That also includes BMI1+BMI2 and stuff. It still just uses -mtune=generic I think, but could hopefully in future ignore tuning things that only matter for CPUs that don’t have AVX2+FMA+BMI2.

The std::vector functions are bulkier since we didn’t use float *__restrict a = avec.data(); or similar to promise non-overlap of the data pointed-to by the std::vector control blocks (and the size isn’t known to be a multiple of the vector width), but the non-cleanup loops for the no-overlap case are vectorized with the same vmulps / vcmpltps / vandps.

See also:

• -ftrapping-math is broken and "never worked" according to GCC dev Marc Glisse. But https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54192 from 2012 proposing to make it not the default is still open.
• How to force GCC to assume that a floating-point expression is non-negative? (various FP options other than the full -ffast-math, such as -fno-math-errno which allows many functions to inline and is not a problem for normal code which doesn’t check errno after calling sqrt or whatever!)
• Semantics of Floating Point Math in GCC
• Auto vectorization on double and ffast-math (of course reductions are only vectorized with -ffast-math or #pragma omp simd reduction (+:my_sum_var), but @phuclv’s answer has some good links)