On Wed, 18 Feb 2026, Richard Sandiford wrote: > "Robin Dapp" <[email protected]> writes: > >> I'd think a specific flag that indicates "never elide" for the > >> vec_predicate > >> could help for that case. I just wonder how to properly annotate the > >> predicate. I'd be hesitant to add even more arguments/operand, even 5 as > >> I > >> proposed is not currently supported out of the box. Maybe an otherwise > >> unused RTL flag can be repurposed? That might be too implicit, though? > > > > Hmm, on the other hand, even for riscv we don't want the predicate to be > > elided. What I'd like is provably dead and side-effect free instructions > > (zero length, mask all false) to be deleted. Our actual vector insns are > > all described with a predicate and won't match without it. > > > > What we do is have the autovec expanders use unpredicated patterns. At the > > first split they are adorned with our unspec predicate. But that mechanism > > should go away and I'd much rather start out with predicates during > > expansion, > > at least for the optimizations that combine et al. can handle themselves. > > > > So my suggestion would instead be to set up the generic code in a way that > > "vec_predicate" would never be elided. > > Yeah. Or at least, not as part of "normal" simpification. Perhaps we > could still have a pass that tries to elimiate predication, if that turns > out to be useful. > > But I can't think of any cases off-hand where nested RTL operations are > interpreted contextually. And IMO that's a good thing that we should > try to preserve. In principle, given: > > (if_then_else (...A...) (...B...) (...C...)) > > it ought to be possible to preevaluate A, B or C in a register without > changing semantics. It's true that the target might not provide patterns > to set A, B or C directly to a register. But semantic correctness > shouldn't rely on a failure to match. > > Same idea for vec_merge. > > So it's beginning to feel to me like vec_predicate should be the > top-level operation, with the vectors as operands, rather than be > something that is nested in another expression. That means that > we won't be able to reuse if_then_else code. But it's sounding > increasingly like that code wouldn't Just Work anyway. > > I also wonder whether, rather than: > > (vec_predicate .... (plus A B)) > > we should instead encode "plus", A and B as direct operands: > > (vec_predicate plus [A B] ...) > > 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.
So besides if_then_else there's also cond_exec. The question is whether we'd want to have (set (reg:..) (vec_predicate plus [A B]..)) or (cond_exec (vec_predicate ...) (set (...) (plus ...)) now, we'd have to introduce "else value" and also have it do per vector lane enablement. But maybe the nested (set ...) is too awkward to deal with? 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)
