On 3/19/26 03:28, Richard Biener via Gcc wrote:
Yes, but for example on x86 the memory order for scatters is defined to
be left-to-right.
which side is lane zero on? left or right? ;-)
on little-endian I'd expect right-to-left if lane 0 were on the right.
there’s a subtle interaction between TSO and vector scatters. although a
vector instruction has a logical width (e.g. 512-bit), in practice it
decomposes into architectural subgroups (often ~128-bit) and further
into micro-architectural quanta (e.g. 256×2 execution, banked caches,
store buffers). execution and visibility therefore occur in smaller,
partially parallel units of execution, and different threads may observe
partial progress depending on micro-architectural effects.
TSO constrains the ordering of stores as they become globally visible,
but it does not inherently require any ordering within a single vector
instruction. intra-vector lane ordering is orthogonal to TSO.
however, x86 defines a lane order for scatters (e.g. to determine which
store wins on conflicts), introducing an additional ordering constraint
at the ISA level that is not strictly required by TSO itself. while this
does not imply full serialization or per-lane global visibility, it does
constrain the abstract behavior more than a fully relaxed model would.
this can be viewed as a potential performance cliff: a very strong
ordering constraint applied within a single instruction, despite being
orthogonal to the guarantees provided by TSO. I think it is too strong,
in practice, implementations still split, merge, and overlap work, and
observable behavior is shaped by store buffering, cache banking, and
other micro-architectural details. the effective execution width is
therefore dynamic and may differ from the nominal vector width.
as a result, relying on predictable outcomes for conflicting scatter
lanes seems unwise to me. a more robust model is to treat scatters as
decomposed operations with largely unspecified internal ordering, even
if the ISA defines a resolution rule for conflicts.
Michael.
