On Thu, 26 Feb 2026, Richard Sandiford wrote: > "Robin Dapp" <[email protected]> writes: > >> Yeah, was just going to reply to your earlier message saying > >> something similar. (cond_exec ...) might be a stretch for something > >> like a predicated addition, since on SVE the set is unconditional: > >> it's always a full register write regardless of the predicate. > >> Having the predication on the rhs seems more accurate there. > >> > >> But we lack a good way of representing predicated stores. Currently > >> SVE uses a read-modify-write of memory, but of course that isn't > >> accurate, since rmw would fault on unmapped addresses. A per-lane > >> cond_exec set could be good for that. > > > > Could we re-use MEM_NOTRAP_P here? I don't remember it being really > > pervasive, and only used in a few places, though. Also not fully > > accurate as we can still trap on active lanes? > > Yeah, like you say, it wouldn't be correct. Active lanes trap as normal > and so things like may_trap_p must return true. > > >> The same problem occurs for predicated loads. (vec_predicate mem ...) > >> would in principle work there, but hiding a mem would be a big change, > >> and would raise the question of where the MEM_ATTRs would go. Urgh... > > > > I'd prefer the vec_predicate/... on the RHS like in the read-modify-write > > way: > > > > (set (mem:V4SI ...) > > (vec_predicate:V4SI "STORE_EXPR" > > (reg:V4SI ...) # reg to store > > (mem:V4SI addr) # merge/old value, could also hold MEM_ATTRs > > # like MEM_NOTRAP_P. > > (mask) (length) ...)) > > > > But we would need something like LOAD_EXPR and STORE_EXPR if we moved the > > operation inside the vec_predicate? :/ > > > >> The code could be stored in the "u2" field of the rtx. And putting > >> the [A B] first would fit better with existing assumptions, since IIRC > >> XVEC (x, n) for n > 0 doesn't occur outside of build-time generators. > >> > >> This again avoids contextual interpretation. A predicated plus is not > >> equivalent to taking an existing unpredicated plus and predicating it, > >> and vice versa. > > > > How important are these properties? I would hope the first one isn't > > too big > > of a deal? > > By "the first", so you mean contextual interpretation? If so, I think > it's pretty important, since most rtl operations recurse on XEXP (...)s > without carrying forward information about the containing operation.
The x86 backend transitioned to UNSPECs for masked loads/stores because of correctness issues, so IMO getting RTL semantics correct is important. Note that the flat (vec_predicate ...) feels a lot like an UNSPEC and we have to avoid making the actual semantics target dependent. Richard. > Thanks, > Richard > -- Richard Biener <[email protected]> SUSE Software Solutions Germany GmbH, Frankenstrasse 146, 90461 Nuernberg, Germany; GF: Jochen Jaser, Andrew McDonald, Werner Knoblich; (HRB 36809, AG Nuernberg)
