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 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. Thanks. juzhe.zh...@rivai.ai From: Robin Dapp Date: 2023-08-22 15:33 To: juzhe.zhong; Andrew Pinski CC: rdapp.gcc; Lehua Ding; gcc-patches@gcc.gnu.org; kito.ch...@gmail.com; pal...@rivosinc.com; jeffreya...@gmail.com Subject: Re: [PATCH] RISC-V: Add conditional unary neg/abs/not autovec patterns > What about conditional zero_extension, sign_extension, > float_extension, ...etc? > > We have discussed this, we can have some many conditional situations > that can be supported by either match.pd or rtl backend combine > pass. > > IMHO, it will be too many optabs/internal fns if we support all of > them in match.pd? Feel free to correct me I am wrong. I think the general trend is (and should be) to push things forward in the pipeline and not just have combine fix it. However, for now this would complicate things and therefore I agree with the approach the patch takes. I'd rather have the patterns in now rather than change the middle end for unclear benefit. IMHO long-term we want things to be optimized early but short-term combine is good enough. We can then move optimizations forward on a case-by-case basis. Regards Robin
