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