> OK. Curious if you've seen this show up in practice and is using the > vaaddu and similar instructions actually profitable?
I remember avg will be presented in somewhere else but not for DImode. I tried to add vaadd related vx combine and notice we don't have DImode for rvv, so make it available before that. > Point is we probably need to be careful here and we probably want a > something in the tuning structure to steer us away from vaaddu and > friends on some designs. I was tentatively planning to have Austin get > that entry into the tuning structure and conditionalize the appropriate > code. I see, thanks Jeff. Pan -----Original Message----- From: Jeff Law <jeffreya...@gmail.com> Sent: Friday, July 18, 2025 1:23 AM To: Li, Pan2 <pan2...@intel.com>; gcc-patches@gcc.gnu.org Cc: juzhe.zh...@rivai.ai; kito.ch...@gmail.com; rdapp....@gmail.com; Chen, Ken <ken.c...@intel.com>; Liu, Hongtao <hongtao....@intel.com> Subject: Re: [PATCH v1] RISC-V: Support RVVDImode for avg3_ceil auto vect On 7/16/25 8:22 AM, pan2...@intel.com wrote: > From: Pan Li <pan2...@intel.com> > > Like the avg3_floor pattern, the avg3_ceil has the > similar issue that lack of the RVV DImode support. > > Thus, this patch would like to support the DImode by > the standard name, with the iterator V_VLSI_D. > > The below test suites are passed for this patch series. > * The rv64gcv fully regression test. > > gcc/ChangeLog: > > * config/riscv/autovec.md (avg<mode>3_ceil): Add new pattern > of avg3_ceil for RVV DImode > > gcc/testsuite/ChangeLog: > > * gcc.target/riscv/rvv/autovec/avg_data.h: Adjust the test data. > * gcc.target/riscv/rvv/autovec/avg_ceil-1-i64-from-i128.c: New test. > * gcc.target/riscv/rvv/autovec/avg_ceil-run-1-i64-from-i128.c: New test. OK. Curious if you've seen this show up in practice and is using the vaaddu and similar instructions actually profitable? I talked to Craig T about this about a year ago and he indicated they hadn't been able to use this family of instructions profitably on their designs due to need to set VXRM (which may trigger a pipeline flush if the designers aren't careful). Point is we probably need to be careful here and we probably want a something in the tuning structure to steer us away from vaaddu and friends on some designs. I was tentatively planning to have Austin get that entry into the tuning structure and conditionalize the appropriate code. Jeff
