On 16/09/2026 20:22, Richard Sandiford wrote:
Richard Sandiford <[email protected]> writes:
How about:
--------------------------------------------------------------------------
This flag only applies to @code{mem}s that have vector addresses (that is,
if the address itself has a vector mode). The flag is nonzero if the
address vector is known to specify independent, non-overlapping memory
locations, so that the @code{mem} never refers to the same byte twice.
Here, ``known to'' and ``never'' mean that the behavior of the program
is undefined if the addresses do overlap, rather than that overlap is
numerically impossible.
This information can be useful when writing to a @code{mem} that has
a vector address. RTL semantics require such writes to behave
@emph{as if} they processed the vector in left-to-right order,
with later writes winning over earlier writes. However, when
@code{MEM_INDEPENDENT_P} is true, the order of the writes does
not matter for RTL semantics and so an instruction could write
to the elements in any order, or in parallel.
--------------------------------------------------------------------------
Is that better in terms of code transformations etc? The idea is that
the flag is an assertion about the address values, rather than a
description of how the mem is used.
I suppose this means that, when MEM_INDEPENDENT_P is true:
local var;
if (cond)
write to (mem (vector referring to var))
cannot be speculatively moved outside of the "if" unless we can prove that
the addresses really are independent, since otherwise we're speculating UB.
But I think that's true however we define this.
Well, ok, I suppose we could limit the type of undefined behaviour to:
- Reading a mem with an incorrect MEM_INDEPENDENT_P will return an
undefined value, but will have no side effects other than reading
from the specified bytes.
Reading from overlapping addresses works just fine, on GCN. I see no
ISA-related reason to apply this flag to reads (although, I take your
point elsewhere about hypothetical compiler transformations using it).
- Similarly, writing to a mem with an incorrect MEM_INDEPENDENT_P will
set the specified bytes to undefined values, but will have no side
effects other than that.
(if that's true for GCN.)
Right, this isn't going to fault or anything, it's just going to write
good data to good addresses, in an undefined order. And it probably is
deterministic on a given device; it's just the ISA manual that's not
saying what the order is (beyond that reads/writes involving different
address spaces -- yes, you can do that in the same vector -- will
complete with differing latancies).
Andrew
