3 ms·

> 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 adva

> 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.

gpderetta 7y ago
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.
- 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 ago
    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.
    - BeeOnRope 7y ago
      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.

gpderetta 7y ago

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.

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 ago
  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.
  - BeeOnRope 7y ago
    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.