4 ms·
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 f
by BeeOnRope 7y ago
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).
- gpderetta 7y agosure, 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.
- BeeOnRope 7y agoAh 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.