Committed, thanks Jeff and Kito. Pan
-----Original Message----- From: Gcc-patches <gcc-patches-bounces+pan2.li=intel....@gcc.gnu.org> On Behalf Of ??? Sent: Wednesday, August 30, 2023 6:27 AM To: Jeff Law <jeffreya...@gmail.com>; kito.cheng <kito.ch...@gmail.com> Cc: gcc-patches <gcc-patches@gcc.gnu.org>; kito.cheng <kito.ch...@sifive.com> Subject: Re: Re: [PATCH] RISC-V: Enable movmisalign for VLS modes > OK for the trunk. Thanks. Will commit it soon. > Does force_reg safe for movmisalign? Both operands[0] and operands[1] are vector QImode already, so it's safe to force reg. And we have fully tested MEM->MEM and CONST->MEM in gcc.dg/vect. juzhe.zh...@rivai.ai From: Jeff Law Date: 2023-08-29 22:23 To: Kito Cheng; Juzhe-Zhong CC: gcc-patches; kito.cheng Subject: Re: [PATCH] RISC-V: Enable movmisalign for VLS modes On 8/29/23 07:54, Kito Cheng via Gcc-patches wrote: >> + /* To support misalign data movement, we should use >> + minimum element alignment load/store. */ >> + unsigned int size = GET_MODE_SIZE (GET_MODE_INNER (<MODE>mode)); >> + poly_int64 nunits = GET_MODE_NUNITS (<MODE>mode) * size; >> + machine_mode mode = riscv_vector::get_vector_mode (QImode, >> nunits).require (); >> + operands[0] = gen_lowpart (mode, operands[0]); >> + operands[1] = gen_lowpart (mode, operands[1]); >> + if (MEM_P (operands[0]) && !register_operand (operands[1], mode)) >> + operands[1] = force_reg (mode, operands[1]); > > Does force_reg safe for movmisalign? It should be. It's a pretty common idiom. Essentially it's going to result in generating this for the MEM->MEM case: MEM->REG REG->MEM Both of which are likely to go through the misalign expander. I was about to ACK when I had to leave for a few minutes. OK for the trunk. jeff
