On 28/07/2026 18:17, Richard Biener wrote:
Am 28.07.2026 um 18:59 schrieb Andrew Stubbs <[email protected]>:
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.
The only way to get this from RTL expansion is through gather (order does not
matter) and scatter (in-order required) both generated via optabs thus the flag
is set from targets. And recog would somehow need to match on it as riscv can
do both in-order and unspecified order.
OK, so expand is not actually a problem because no current gimple
generates such things directly; got it. The scatter_store patterns can
do as required.
Also, since scatter operations use fixed strides the question of
in-order, or not, is actually a non-issue even on GCN so we could set
the flag safely.
As for the recog issue, can predicates not take care of that?
(define_predicate "riscv_in_order_vector_mem"
(and (match_operand 0 "memory_operand")
(match_test "MEM_IN_ORDER_WRITE_P (op)")))
Andrew
Richard
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
