Andrew Stubbs <[email protected]> writes: > 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".
I'm not sure it should be MEM_IN_ORDER_WRITE vs not. That seems more like a property of the operation, rather than a property of the mem object itself. Instead I think the useful information is "guaranteed indepenent addresses" vs not, where "independent" means "not overlapping". As discussed downthread, we'd have to assume that addresses might overlap unless we have specific information to the contrary, so I think "independent" should be 1 and the default/conservative "possibly overlapping" should be 0. Then we could define, for now, that setting a mem whose addresses might overlap is done left-to-right, as a scatter. Thanks, Richard
