On 29/07/2026 10:54, Richard Sandiford wrote:
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.
Agreed, MEM_INDEPENDENT works too, and still fits /i neatly.
However, this implies that there might be multiple ways to handle
non-independent MEMs, and I think that's not true: it really does have
to be in-order or nothing.
Anyway, this matters little to me. I'm happy to specify whichever. It'll
be trivial to set the flag in my code, and only targets that accept
vectors as "legitimate addresses" will be affected, which means only GCN
to start.
Andrew
