On 28/07/2026 17:21, Richard Sandiford wrote:
Andrew Stubbs <[email protected]> writes:
On 28/07/2026 12:54, Richard Biener wrote:
[...]
Just to add that (mem:<vector> ..) with unordered semantics ties us to that
unless we want to have a flag on the mem to have left-to-right semantics.
Given it in theory should be made to fit gather/scatter modelling (ignoring
the masking representational issue). So I'd like at least that thought out,
if not documented and implemented (having the flag and printing it).
Agreed FWIW.
I think it would be good to think about the masking issue too, given
Robin's parallel discussion about having a better representation of
predication. Again, just in terms of having a plausible approach
thought out, rather than being implemented in the first version.
I believe the /i and /s flags are available, if we should choose to use
them.
Would a target hook not be sufficient though? These things are likely to
be true always or never, for any given mode, on most architectures.
Better even, as such flags are somewhat likely to "get lost" in all the
random places that manipulate MEM.
Please don't use a hook! :) IMO RTL semantics should stand on their own
as far as possible. I realise there are exceptions, like STORE_FLAG_VALUE
and SHIFT_COUNT_TRUNCATED, but even there, I think it would have been
better to make the RTL operators self-descriptive and use the macros
to control which operator is generated.
Making SHIFT_COUNT_TRUNCATED apply to all shift rtxes has been a problem
in the past and using a hook here might end up the same way.
OK, let's say MEM_IN_ORDER_WRITE with /i then? If the flag is not
present then the order is undefined. It could work the other way around,
but this seemed to fit nicer with "i".
How does it get written at expand time? Does the expand pass just assume
that all gimple vector operators are "in-order"? Is there a hook for
*that*? Ordered/unordered optabs? The legitimate/legitimize hooks can't
do anything with flags because they only see the address expression.
If we're just assuming in-order by default, the code produced would
actually be unsuitable for GCN. Except it isn't, of course, because
autovectorization (and OpenMP parallel, etc) require that the loop
iterations are independent, and therefore we choose to assume (rightly
or wrongly) that using the writes that we have are safe.
But GCN would have to somehow go though and remove all those flags, or
else whatever RTL optimizer it is that cares about such things would be
getting misinformed.
Andrew
