"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. Thanks, Richard
