Thanks Jeff. > Presumably with the way this has been implemented, it looks like adding > vasub ought to be pretty easy. Just add it to the > expand_vx_binary_vxrm_* routines, the appropriate iterator and tests, > right?
Absolutely yes, just like what we do in previous. Pan -----Original Message----- From: Jeff Law <jeffreya...@gmail.com> Sent: Wednesday, July 23, 2025 9:22 PM 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 0/2] Avoid RVV fixed insn VX combine pollute VXRM On 7/22/25 11:06 PM, pan2...@intel.com wrote: > From: Pan Li <pan2...@intel.com> > > The RVV fixed point insn VX combine should focus on the insn itself, > instead of any standard name like avg_floor, the vxrm should be > the value of insn as is. > > The below test suites are passed for this patch series. > * The rv64gcv fully regression test. > > Pan Li (2): > RISC-V: Avoid vaaddu.vx combine pattern pollute VXRM csr > RISC-V: Add test case for vx combine polluting VXRM OK for the trunk. Presumably with the way this has been implemented, it looks like adding vasub ought to be pretty easy. Just add it to the expand_vx_binary_vxrm_* routines, the appropriate iterator and tests, right? Assuming that's basically the case, then those patches are pre-approved. Jeff
