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