Jeff Law <jeffreya...@gmail.com> writes: > On 8/22/23 02:08, juzhe.zh...@rivai.ai wrote: >> Yes, I agree long-term we want every-thing be optimized as early as >> possible. >> >> However, IMHO, it's impossible we can support every conditional patterns >> in the middle-end (match.pd). >> It's a really big number. >> >> For example, for sign_extend conversion, we have vsext.vf2 (vector SI -> >> vector DI),... vsext.vf4 (vector HI -> vector DI), vsext.vf8 (vector QI >> -> vector DI).. >> Not only the conversion, every auto-vectorization patterns can have >> conditional format. >> For example, abs,..rotate, sqrt, floor, ceil,....etc. >> I bet it could be over 100+ conditional optabs/internal FNs. It's huge >> number. >> I don't see necessity that we should support them in middle-end >> (match.pd) since we known RTL back-end combine PASS can do the good job >> here. >> >> Besides, LLVM doesn't such many conditional pattern. LLVM just has "add" >> and "select" separate IR then do the combine in the back-end: >> https://godbolt.org/z/rYcMMG1eT <https://godbolt.org/z/rYcMMG1eT> >> >> You can see LLVM didn't do the op + select optimization in generic IR, >> they do the optimization in combine PASS. >> >> So I prefer this patch solution and apply such solution for the future >> more support : sign extend, zero extend, float extend, abs, sqrt, ceil, >> floor, ....etc. > It's certainly got the potential to get out of hand. And it's not just > the vectorizer operations. I know of an architecture that can execute > most of its ALU and loads/stores conditionally (not predication, but > actual conditional ops) like target = (x COND Y) ? a << b ; a) > > I'd tend to lean towards synthesizing these conditional ops around a > conditional move/select primitive in gimple through the RTL expanders. > That would in turn set things up so that if the target had various > conditional operations like conditional shift it could be trivially > discovered by the combiner.
FWIW, one of the original motivations behind the COND_* internal functions was to represent the fact that the operation is suppressed (rather than being performed and discarded) when the predicate is false. This allows if-conversion for FP operations even in strict FP modes, since inactive lanes are guaranteed not to generate an exception. I think it makes sense to add COND_* functions for anything that can reasonably be done on FP types, and that could generate an FP exception. E.g. sqrt was one of the examples mentioned, and I think COND_SQRT is something that we should have. I agree it's less clear-cut for purely integer stuff, or for FP operations like neg and abs that are pure bit manipulation. But perhaps there's a question of how many operations are only defined for integers, and whether the number is high enough for them to be treated differently. I wouldn't have expected an explosion of operations to be a significant issue, since (a) the underlying infrastructure is pretty mechanical and (b) any operation that a target supports is going to need an .md pattern whatever happens. Thanks, Richard
