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
