In HPC, we use `#pragma omp simd`.

`#pragma omp imd` should force the vectorization, but maybe not the hoisting, I don't know. Could be nice to check.

Edit:

Clang fail: ``` <source>:5:5: warning: loop not vectorized: the optimizer was unable to perform the requested transformation; the transformation might be disabled or specified as part of an unsupported transformation ordering [-Wpass-failed=transform-warning]

    #pragma omp simd 

    ^

1 warning generated. Compiler returned: 0 ```

But ICC seems happy with it.

it works on my test:

   https://godbolt.org/z/sSSdjw

where ivdep fails. Nice!

You do need -fopenmp of course.

edit:

strangely, it still fails to vectorize the original vector example.

> the compiler should be able to assume that a previous write cannot affect the next read from the size field, but it seems that neither GCC nor clang take advantage of it.

Why?

Good point about #pragma ivdep. I feel like the semantics of that one are a bit less than rigorous, but it's a useful tool.

Why they do not take advantage ov ivdep? I don't know. I thought it was because the size address was not a function of the iteration variable, but even by artificially adding the dependency (with a barebone vector implementation) does not seem to trigger the optimization.

I mean why "should [the compiler] be able to assume that a previous write cannot affect the next read from the size field"?

It's not that the size field is a function of the iteration variable (i?) but that the previous write may have overwritten the size field, because the size field is located at some arbitrary place in memory, and the array backing the vector is located at some other arbitrary place and they may overlap (but only because the vector type is uint8_t/char - if it other than a char type the compiler can be sure they don't overlap because the size() fields are pointers which have a distinct type from uint32_t and are not subject to the "char aliasing loophole" rule).

sure, but ivdep is supposed to explicitly tells the compiler that there are no loop carried dependencies between iterations, so iteration i-1 couldn't possibly write to a memory location read by iteration i.

Ah sorry, I read your ivdep sentence and the second part of your post as independent, i.e,. that the compiler should be able to assume this (even without ivdep).

I realize now you were saying "[With ivdep] and in this specific case, the compiler should be able to assume..."

It makes sense now.