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