> I'd love to hear Richard S's thoughts on the gen* bits, but they > generally looked sensible to me.
I'm afraid I need to gently ping Richard S (who is away right now) here as well before signing off for several days. I would have hoped that we could converge at least on a minimally implementable solution before Cauldron so it still has a chance to be GCC 17 viable. It sounded to me like Richi preferred a variant with a bit more structure than the one this patch implements and I'm also not a big fan of how it currently "reads". A source of concern for a more regular shape was contextual interpretation. Apparently, though, we're having a similar problem with COND_EXEC where we avoid "hoisting" or "sinking" already. Also COND_EXEC has an optional "data" field that I'd like to re-use as well for a vector predicate (for riscv payload) but which is not yet in this RFC. I haven't made a lot of progress here but we'd really like to have this in one form or another because it would help with several currently very difficult to fix target issues. As riscv target we're open to being the guinea pig for new predicate. If the first shot isn't great, we can still adjust. Richi was also concerned about a third variant of representing vec_merge and vec_concat/vec_select. I suppose vec_merge is the most likely candidate to be superseded by a vec_predicate as vec_select is more generic. Ideally, long-term, we'd limit vec_select to the actual permutation-like situations and express merge/predicate cases as one. Another significant chunk of vec_select usage is vec extraction and vec set which I'd like to handle by explicit rtl codes. All that could help trim the wild growth a little, but it would always be a process, not an immediate solution. -- Regards Robin
