[V2] RISC-V: Replace not + bitwise_imm with li + bitwise_not

In the case when we have C code like this int foo (int a) { return 100 & ~a; } GCC generates the following instruction sequence foo: not a0,a0 andia0,a0,100 ret This patch replaces that with this sequence foo: li a5,100 andn a0,a5,a0 ret The profitabili

RISC-V: Replace not + bitwise_imm with li + bitwise_not

In the case when we have C code like this int foo (int a) { return 100 & ~a; } GCC generates the following instruction sequence foo: not a0,a0 andia0,a0,100 ret This patch replaces that with this sequence foo: li a5,100 andn a0,a5,a0 ret The profitabili

Re: RISC-V: Fix stack_save_restore_1/2 test cases

wrote: > Hi Jivan, > > On 8/24/23 08:45, Jivan Hakobyan via Gcc-patches wrote: > > This patch fixes failing stack_save_restore_1/2 test cases. > > After 6619b3d4c15c commit size of the frame was changed. > > > > > > gcc/testsuite/ChangeLog: > >

RISC-V: Fix stack_save_restore_1/2 test cases

This patch fixes failing stack_save_restore_1/2 test cases. After 6619b3d4c15c commit size of the frame was changed. gcc/testsuite/ChangeLog: * gcc.target/riscv/stack_save_restore_1.c: Update frame size * gcc.target/riscv/stack_save_restore_2.c: Likewise. -- With the best regar

Re: IRA update_equiv_regs for (was Re: ICE for interim fix for PR/110748)

Yes, as mentioned Jeff I have some work in that scope. The first is related to address computation when it has a large constant part. Suppose we have this code: int consume (void *); int foo (void) { int x[1000]; return consume (x); } before IRA we have the following s

Re: RISC-V: Folding memory for FP + constant case

Thank you for your effort. I had evaluated only in intrate tests. I am glad to see the same result on Leela. On Tue, Aug 1, 2023 at 11:14 PM Vineet Gupta wrote: > > > On 7/25/23 20:31, Jeff Law via Gcc-patches wrote: > > > > > > On 7/25/23 05:24, Jivan Hakobyan wrote: > >> Hi. > >> > >> I re-run

RISC-V: Replace unspec with bitreverse in riscv_brev8_ insn

This small patch replaces unspec opcode with bitreverse in riscv_brev8_ insn. gcc/ChangeLog: * config/riscv/crypto.md (UNSPEC_BREV8): Remov. (riscv_brev8_): Use bitreverse opcode. -- With the best regards Jivan Hakobyan diff --git a/gcc/config/riscv/crypto.md b/gcc/config/riscv/

Re: RISC-V: Folding memory for FP + constant case

er 1.3 B times and contains 5 memory folding cases (5 redundant moves). Besides that, I have checked the build failure on x264_r. It is already fixed on the third version. On Sat, Jul 15, 2023 at 10:16 AM Jeff Law wrote: > > > On 7/12/23 14:59, Jivan Hakobyan via Gcc-patches wrote: > &g

RISC-V: Folding memory for FP + constant case

Accessing local arrays element turned into load form (fp + (index << C1)) + C2 address. In the case when access is in the loop we got loop invariant computation. For some reason, moving out that part cannot be done in loop-invariant passes. But we can handle that in target-specific hook (legitimize

Re: LTO: buffer overflow in lto_output_init_mode_table

Hi Robbin. Thank you for responding. I will defer my thread. On Thu, Jun 22, 2023 at 3:42 PM Robin Dapp wrote: > Hi Jivan, > > I think Pan is already on this problem. Please see this thread: > https://gcc.gnu.org/pipermail/gcc-patches/2023-June/622129.html > > Regards > Robin > -- With th

LTO: buffer overflow in lto_output_init_mode_table

In the case when enabled -flto=N GCC aborted compilation. The reason is the overflowing streamer_mode_table buffer. It has 1 << 8 bytes but lto_output_init_mode_table() tries to fill with MAX_MACHINE_MODE bytes. gcc/ChangeLog: * tree-streamer.h (streamer_mode_table): Changed buffer size

[wwwdocs] Broken URL to README in st/cli-be project

In CLI project link to README is broken. This patch fixes that. Discussed in PR110250 -- With the best regards Jivan Hakobyan diff --git a/htdocs/projects/cli.html b/htdocs/projects/cli.html index 380fb031..394832b6 100644 --- a/htdocs/projects/cli.html +++ b/htdocs/projects/cli.html @@ -145,7 +

[wwwdocs] Broken URL to README.Portability

This patch fixes the link to README.Portability in "GCC Coding Conventions" page -- With the best regards Jivan Hakobyan diff --git a/htdocs/codingconventions.html b/htdocs/codingconventions.html index 9b6d243d..f5a356a8 100644 --- a/htdocs/codingconventions.html +++ b/htdocs/codingconventions.h

Remove MFWRAP_SPEC remnant

This patch removes a remnant of mudflap. gcc/ChangeLog: * config/moxie/uclinux.h (MFWRAP_SPEC): Remove -- With the best regards Jivan Hakobyan diff --git a/gcc/config/moxie/uclinux.h b/gcc/config/moxie/uclinux.h index f7bb62e56c7..a7d371047c4 100644 --- a/gcc/config/moxie/uclinux.h +++

[RFC] RISC-V: Eliminate extension after for *w instructions

`This patch tries to prevent generating unnecessary sign extension after *w instructions like "addiw" or "divw". The main idea of it is to add SUBREG_PROMOTED fields during expanding. I have tested on SPEC2017 there is no regression. Only gcc.dg/pr30957-1.c test failed. To solve that I did some c

RISC-V: Use extension instructions instead of bitwise "and"

In the case where the target supports extension instructions, it is preferable to use that instead of doing the same in other ways. For the following case void foo (unsigned long a, unsigned long* ptr) { ptr[0] = a & 0xUL; ptr[1] &= 0xUL; } GCC generates foo: li

[v2] RISC-V: Remove masking third operand of rotate instructions

Rotate instructions do not need to mask the third operand. For example, RV64 the following code: unsigned long foo1(unsigned long rs1, unsigned long rs2) { long shamt = rs2 & (64 - 1); return (rs1 << shamt) | (rs1 >> ((64 - shamt) & (64 - 1))); } Compiles to: foo1: andia1,a1,

RISC-V: Remove masking third operand of rotate instructions

Rotate instructions do not need to mask the third operand. For example RV64 the following code: unsigned long foo1(unsigned long rs1, unsigned long rs2) { long shamt = rs2 & (64 - 1); return (rs1 << shamt) | (rs1 >> ((64 - shamt) & (64 - 1))); } Compiles to: foo1: andia1,a1,6

RISC-V: Eliminate redundant zero extension of minu/maxu operands

RV64 the following code: unsigned Min(unsigned a, unsigned b) { return a < b ? a : b; } Compiles to: Min: zext.w a1,a1 zext.w a0,a0 minua0,a1,a0 sext.w a0,a0 ret This patch removes unnecessary zero extensions of minu/maxu operands. gcc/Chang

RISC-V: avoid splitting small constants in bcrli_nottwobits patterns

Hi all. I have noticed that in the case when we try to clear two bits through a small constant, and ZBS is enabled then GCC split it into two "andi" instructions. For example for the following C code: int foo(int a) { return a & ~ 0x101; } GCC generates the following: foo: andi a0,