RE: [PATCH] RISC-V: Support simplify (-1-x) for vector.

Hi Jeff, Thank you so much for the note and testing :D. I'll attach the test result next time. Thanks, Yanzhang > -Original Message- > From: Jeff Law > Sent: Thursday, August 17, 2023 12:33 PM > To: Wang, Yanzhang ; gcc-patches@gcc.gnu.org > Cc: juzhe.zh...@rivai.ai; kito.ch...@sifive.c

RE: [PATCH v3] RISCV: Add -m(no)-omit-leaf-frame-pointer support.

Hi Jeff, Do you have any further comments about this patch ? Thanks, Yanzhang > -Original Message- > From: Jeff Law > Sent: Friday, July 21, 2023 12:11 PM > To: Kito Cheng ; Wang, Yanzhang > > Cc: gcc-patches@gcc.gnu.org; juzhe.zh...@rivai.ai; kito.ch...@sifive.com; > Li, Pan2 > Subje

RE: [PATCH v2] RISC-V: convert the mulh with 0 to mov 0 to the reg.

Thanks your comments, Jeff and Robin > > Is the mulh case somehow common or critical? > Well, I would actually back up even further. What were the > circumstances that led to the mulh with a zero operand? I think you both mentioned why should we add the mulh * 0 simplify. Unfortunately, I hav

RE: [PATCH v2] RISC-V: convert the mulh with 0 to mov 0 to the reg.

This is a draft patch. I would like to explain it's hard to make the simplify generic and ask for some help. There're 2 categories we need to optimize. - The op in optab such as div / 1. - The unspec operation such as mulh * 0, (vadc+vmadc) + 0. Especially for the unspec operation, I found we ne

RE: [PATCH] RISCV: Add -m(no)-omit-leaf-frame-pointer support.

Hi Jeff, sorry for the late reply. > The long branch handling is done at the assembler level. So the clobbering > of $ra isn't visible to the compiler. Thus the compiler has to be > extremely careful to not hold values in $ra because the assembler may > clobber $ra. If assembler will modify the

RE: Re: [PATCH] RISC-V: convert the mulh with 0 to mov 0 to the reg.

Of cause, I'd like to make it generic. Thanks Robin’s advice! It's right, there're many similar situations. But I'm not sure how to distinguish different operations. Currently, the VMULH is fixed as below. + (unspec:VI_QHS + [(vec_duplicate:VI_QHS +

RE: [PATCH] RISC-V: convert the mulh with 0 to mov 0 to the reg.

Thanks, you are right. I have not considered the iterator much. I picked it from one of pred_mulh directly. It should be able to work with VFULL_I. Yanzhang From: juzhe.zh...@rivai.ai Sent: Wednesday, June 21, 2023 2:21 PM To: Wang, Yanzhang ; gcc-patches Cc: Kito.cheng ; Li, Pan2 ; Wang, Yan

RE: [PATCH v5] RISC-V: Add vector psabi checking.

> settle down the ABI and for GCC 13. > > On Mon, Jun 12, 2023 at 10:34 PM Jeff Law wrote: > > > > > > > > On 6/12/23 07:36, Wang, Yanzhang via Gcc-patches wrote: > > > I found that add the -Wno-psabi to CFLAGS will be overrode by > > > dg-options.

RE: [PATCH v5] RISC-V: Add vector psabi checking.

-patches@gcc.gnu.org; > juzhe.zh...@rivai.ai; Li, Pan2 > Subject: Re: [PATCH v5] RISC-V: Add vector psabi checking. > > How about appending to DEFAULT_CFLAGS? > > On Mon, Jun 12, 2023 at 9:38 PM Wang, Yanzhang via Gcc-patches patc...@gcc.gnu.org> wrote: > > > > I found

RE: [PATCH v5] RISC-V: Add vector psabi checking.

I found that add the -Wno-psabi to CFLAGS will be overrode by dg-options. It seems we can only add this option to the third arg of dg-runtest. Attach the dg-runtest comments, # dg-runtest -- simple main loop useful to most testsuites # # OPTIONS is a set of options to always pass. # DEFAULT_EXTRA_

RE: [PATCH v5] RISC-V: Add vector psabi checking.

I found there're still some test cases that does not pass. I'll push another version soon. Sorry for the inconvenience. > -Original Message- > From: Wang, Yanzhang > Sent: Monday, June 12, 2023 4:08 PM > To: gcc-patches@gcc.gnu.org > Cc: juzhe.zh...@rivai.ai; kito.ch...@sifive.com; Li, Pa

RE: [PATCH v4] RISC-V: Add vector psabi checking.

I reproduce the failure too. Because it returns early in get_arg_info for v-ext mode. I'll move the checking to the beginning. > -Original Message- > From: Kito Cheng > Sent: Friday, June 9, 2023 5:52 PM > To: Wang, Yanzhang > Cc: gcc-patches@gcc.gnu.org; juzhe.zh...@rivai.ai; kito.ch...

RE: [PATCH] RISCV: Add -m(no)-omit-leaf-frame-pointer support.

Hi Jeff, Thanks your comments. I have few questions that I don't quite understand. > One of the things that needs to be upstreamed is long jump support within > a function. Essentially once a function reaches 1M in size we have the > real possibility that a direct jump may not reach its target.

RE: [PATCH] RISCV: Add -m(no)-omit-leaf-frame-pointer support.

> +static bool > +riscv_frame_pointer_required (void) > +{ > + if (riscv_save_frame_pointer && !crtl->is_leaf) > +return true; > + > + return false; > +} > > Can be simplified to return riscv_save_frame_pointer && !crtl->is_leaf; Nice. It's much simpler. Will modify in another patch. > +

Re: [PATCH] RISCV: Add -m(no)-omit-leaf-frame-pointer support.

Hi Jeff, Yes, there's a requirement to support backtrace based on the fp+ra. And the unwind/cfa is not acceptable because it will add additional sections to the binary. Currently, -fno-omit-frame-pointer can not save the ra for the leaf function. So we need to add another option like ARM/X86 to su

RE: [PATCH v5] RISC-V: Fix regression of -fzero-call-used-regs=all

Hi Kito, Juzhe, Jeff, Thanks for your kindly reviews. I have modified based on the comments and ran the testsuite on my local. Could you please take another look ? If any more comments please let me know. Thanks Yanzhang > -Original Message- > From: Wang, Yanzhang > Sent: Tuesday, Apr

RE: [PATCH v3] RISC-V: Fix regression of -fzero-call-used-regs=all

Thanks Jeff's comment. > Presumably the difficulty here is we need to find a suitable hard > register so that we can emit the vsetvl. Yes. We use the GPR which has been flagged in the need_zeroed_regs to hold the vl. There should be one GPR we can use, otherwise, will throw an exception. > Do