[RFC PATCH 1/1] RISC-V: Make SHA-256, SM3 and SM4 builtins operate on uint32_t

From: Tsukasa OI This is in parity with the LLVM commit 599421ae36c3 ("[RISCV] Re-define sha256, Zksed, and Zksh intrinsics to use i32 types."). SHA-256, SM3 and SM4 instructions operate on 32-bit integers and upper 32-bits have no effects on RV64 (the output is sign-extended from the original 3

[PATCH v5] RISC-V:Optimize the MASK opt generation

Accoring to Kito's advice, using "MASK(name) Var(other_flag_name)" to generate MASK and TARGET MACRO automatically. This patch improve the MACRO generation of MASK_* and TARGET_*. Due to the more and more riscv extensions are added, the default target_flag is full. Before this patch,if you want to

[PATCH] LoongArch: Enable -fsched-pressure by default at -O1 and higher.

gcc/ChangeLog: * common/config/loongarch/loongarch-common.cc: (default_options loongarch_option_optimization_table): Default to -fsched-pressure. --- gcc/common/config/loongarch/loongarch-common.cc | 1 + 1 file changed, 1 insertion(+) diff --git a/gcc/common/config/loon

Re: Re: [PATCH 3/3] [V2] [RISC-V] support cm.mva01s cm.mvsa01 in zcmp

On 2023-09-08 04:33  Palmer Dabbelt wrote: > >On Thu, 07 Sep 2023 13:16:36 PDT (-0700), dimi...@dinux.eu wrote: >> Hi, >> >> This patch appears to have caused PR 111259. Hi Patrick  We're reproducing the issue also.  One thing that puzzles me is why a zcmp predicate casused a regression in rv64

Re: [PATCH] libstdc++: Reduce output of 'make check'

Maybe use $(AM_V_at) instead? That would allow it to be controlled by the --enable-silent-rules flag to configure, as well as make V=1 vs. make V=0 too. On Thu, Sep 7, 2023 at 9:32 AM Jonathan Wakely via Gcc-patches wrote: > > Any objections to this change? > > -- >8 -- > > This removes the 39 li

[PATCH] Remove constraint modifier % for fcmaddcph/fcmulcph since there're not commutative.

Bootstrapped and regtested on x86_64-pc-linux-gnu{-m32,} on SPR. Ready push to trunk and backport to GCC13/GCC12. gcc/ChangeLog: PR target/111306 * config/i386/sse.md (int_comm): New int_attr. (fma__): Remove % for Complex conjugate operations since they're not

[PATCH] Support folding min(poly,poly) to const

Hi, This patch adds support that tries to fold `MIN (poly, poly)` to a constant. Consider the following C Code: ``` void foo2 (int* restrict a, int* restrict b, int n) { for (int i = 0; i < 3; i += 1) a[i] += b[i]; } ``` Before this patch: ``` void foo2 (int * restrict a, int * restri

Re: [PATCH] Support folding min(poly,poly) to const

On Thu, Sep 7, 2023 at 10:25 PM Lehua Ding wrote: > > Hi, > > This patch adds support that tries to fold `MIN (poly, poly)` to > a constant. Consider the following C Code: Does it make sense to handle max also? Thanks, Andrew > > ``` > void foo2 (int* restrict a, int* restrict b, int n) > { >

[PATCH] riscv: xtheadbb: Fix extendqi insn

From: Christoph Müllner Recently three SPEC CPU 2017 benchmarks broke when using xtheadbb: * 500.perlbench_r * 525.x264_r * 557.xz_r Tracing the issue down revealed, that we emit a 'th.ext xN,xN,15,0' for a extendqi insn, which is obviously wrong. This patch splits the common 'extend2_th_ext' in

Re: [PATCH] Support folding min(poly,poly) to const

Hi Andrew, On 2023/9/8 13:28, Andrew Pinski wrote: On Thu, Sep 7, 2023 at 10:25 PM Lehua Ding wrote: Hi, This patch adds support that tries to fold `MIN (poly, poly)` to a constant. Consider the following C Code: Does it make sense to handle max also? At the moment I can't construct a C

[PATCH] riscv: thead: Fix mode attribute for extension patterns

From: Christoph Müllner The mode attribute of an extension pattern is usually set to the target type. Let's follow this convention consistently for xtheadbb. Signed-off-by: Christoph Müllner gcc/ChangeLog: * config/riscv/thead.md: Use more appropriate mode attributes for exten

Re: [PATCH V5 0/3] RISC-V: Add an experimental vector calling convention

Pushed to trunk with few testcase modifications, e.g. adding { target { riscv_vector } } to dg-run and adding -march / -mabi for compile tests. Thank you so much Kito for your help :) -- Best, Lehua

Re: [PATCH] Support folding min(poly,poly) to const

Lehua Ding writes: > Hi, > > This patch adds support that tries to fold `MIN (poly, poly)` to > a constant. Consider the following C Code: > > ``` > void foo2 (int* restrict a, int* restrict b, int n) > { > for (int i = 0; i < 3; i += 1) > a[i] += b[i]; > } > ``` > > Before this patch: >

[PATCH] riscv: bitmanip: Remove duplicate zero_extendhi2 pattern

From: Christoph Müllner We currently have two identical zero_extendhi2 patterns: * '*zero_extendhi2_zbb' * '*zero_extendhi2_bitmanip' This patch removes the *_zbb pattern and ensures that all sign- and zero-extensions use the postfix '_bitmanip'. Signed-off-by: Christoph Müllner gcc/ChangeLog

[PATCH V2] Support folding min(poly,poly) to const

Hi, This patch adds support that tries to fold `MIN (poly, poly)` to a constant. Consider the following C Code: ``` void foo2 (int* restrict a, int* restrict b, int n) { for (int i = 0; i < 3; i += 1) a[i] += b[i]; } ``` Before this patch: ``` void foo2 (int * restrict a, int * restri

Re: [PATCH] Support folding min(poly,poly) to const

Hi Richard, On 2023/9/8 14:37, Richard Sandiford wrote: I think this should instead use poly_int_tree_p and wi::to_poly_widest. There's no need to handle int64 and uint64 separately. (And there's no need to handle just 64-bit types.) Thanks for the correction. I used wi::to_poly_wide(instead

<    1   2