[PATCH v1] RISC-V: Support RVV VFWMACC rounding mode intrinsic API

From: Pan Li This patch would like to support the rounding mode API for the VFWMACC as the below samples. * __riscv_vfwmacc_vv_f64m2_rm * __riscv_vfwmacc_vv_f64m2_rm_m * __riscv_vfwmacc_vf_f64m2_rm * __riscv_vfwmacc_vf_f64m2_rm_m Signed-off-by: Pan Li gcc/ChangeLog: * config/riscv/ri

[PATCH] Add clang's invalid-noreturn warning flag

Please review a patch to add clang's invalid-noreturn flag to toggle noreturn warnings. This patch keeps the old behaviour of always warning on every noreturn violation, but unlike clang also adds an extra layer of fine tuning by turning invalid-noreturn into a warning with levels, where level 1 w

Re: [RFC] [v2] Extend fold_vec_perm to handle VLA vectors

On Thu, 10 Aug 2023 at 21:27, Richard Sandiford wrote: > > Prathamesh Kulkarni writes: > >> static bool > >> is_simple_vla_size (poly_uint64 size) > >> { > >> if (size.is_constant ()) > >> return false; > >> for (int i = 1; i < ARRAY_SIZE (size.coeffs); ++i) > >> if (size[i] != (i <=

Re: [PATCH] sso-string@gnu-versioned-namespace [PR83077]

Here is the fixed patch tested in all 3 modes: - _GLIBCXX_USE_DUAL_ABI - !_GLIBCXX_USE_DUAL_ABI && !_GLIBCXX_USE_CXX11_ABI - !_GLIBCXX_USE_DUAL_ABI && _GLIBCXX_USE_CXX11_ABI I don't know what you have in mind for the change below but I wanted to let you know that I tried to put COW std::basic

[pushed] modula-2, plugin: Fix Darwin bootstrap issues.

Tested on x86_64 Darwin and x86_64 Linux, pushed to master, will also backport to 13 if it is needed there, thanks Iain --- 8< --- This corrects some typos in the suffix of the m2rte pluing that lead to a bootstrap fail on Darwin, where the suffix is not '.so'. On some versions of Darwin, the li

[no subject]

>From d57ac4f9a095a2f616863efd524ac2d87276becb Mon Sep 17 00:00:00 2001 From: Eddy Young Date: Sun, 13 Aug 2023 19:59:12 +0100 Subject: [PATCH] gcc/reload.h: Change type of x_spill_indirect_levels --- ChangeLog| 5 + gcc/reload.h | 2 +- 2 files changed, 6 insertions(+), 1 deletion(-) d

Re:

On Sun, Aug 13, 2023 at 12:05 PM Eddy Young Tie Yang wrote: > > From d57ac4f9a095a2f616863efd524ac2d87276becb Mon Sep 17 00:00:00 2001 > From: Eddy Young > Date: Sun, 13 Aug 2023 19:59:12 +0100 > Subject: [PATCH] gcc/reload.h: Change type of x_spill_indirect_levels > > --- > ChangeLog| 5 +++

[PATCH] gcc/reload.h: Change type of x_spill_indirect_levels

This patch changes the type of `x_spill_indirect_levels` member of `struct target reload` from `bool` to `unsigned char`. Without this change, the build of esp-open-sdk fails with GCC 11 and above. (Please bear with me, this is my first patch submission.) Cheers, Eddy --- Chang

Re: [PATCH] gcc/reload.h: Change type of x_spill_indirect_levels

On Sun, Aug 13, 2023 at 12:20 PM Eddy Young wrote: > > This patch changes the type of `x_spill_indirect_levels` member of > `struct target reload` from `bool` to `unsigned char`. > > Without this change, the build of esp-open-sdk fails with GCC 11 and > above. This was done back in d57c99458933 f

Re: [PATCH] gcc/reload.h: Change type of x_spill_indirect_levels

On Sun, Aug 13, 2023 at 12:24:28PM -0700, Andrew Pinski wrote: > Date: Sun, 13 Aug 2023 12:24:28 -0700 > From: Andrew Pinski > To: Eddy Young > Cc: gcc-patches@gcc.gnu.org > Subject: Re: [PATCH] gcc/reload.h: Change type of x_spill_indirect_levels > > On Sun, Aug 13, 2023 at 12:20 PM Eddy Young

Re: [PATCH] sso-string@gnu-versioned-namespace [PR83077]

Here is another version with enhanced sizeof/alignof static_assert in string-inst.cc for the std::__cow_string definition from . The assertions in cow-stdexcept.cc are now checking the definition which is in the same file. On 13/08/2023 15:27, François Dumont wrote: Here is the fixed patch t

Re: [RFC PATCH 0/2] RISC-V: __builtin_riscv_pause for all environment

On Sat, 12 Aug 2023 at 01:31, Jeff Law via Gcc-patches wrote: > > > > On 8/9/23 16:39, Tsukasa OI wrote: > > On 2023/08/10 5:05, Jeff Law wrote: > > >> I'd tend to think we do not want to expose the intrinsic unless the > >> right extensions are enabled -- even though the encoding is a no-op and >

[PATCH v2 1/2] libstdc++: Implement more maintainable header

This commit replaces the ad-hoc logic in with an AutoGen database that (mostly) declaratively generates a version.h bit which combines all of the FTM logic across all headers together. This generated header defines macros of the form __glibcxx_foo, equivalent to their __cpp_lib_foo variants, acco

Re: [RFC PATCH 0/2] RISC-V: __builtin_riscv_pause for all environment

On Sun, Aug 13, 2023 at 12:53 PM Philipp Tomsich wrote: > > On Sat, 12 Aug 2023 at 01:31, Jeff Law via Gcc-patches > wrote: > > > > > > > > On 8/9/23 16:39, Tsukasa OI wrote: > > > On 2023/08/10 5:05, Jeff Law wrote: > > > > >> I'd tend to think we do not want to expose the intrinsic unless the >

Re: [PATCH v4 1/8] libcpp: Add LC_GEN linemaps to support in-memory buffers

On Fri, Aug 11, 2023 at 06:45:31PM -0400, David Malcolm wrote: > On Wed, 2023-08-09 at 18:14 -0400, Lewis Hyatt wrote: > > Hi Lewis, thanks for the patch... > > > Add a new linemap reason LC_GEN which enables encoding the location of data > > that was generated during compilation and does not app

Re: [PATCH 2/2] ipa-cp: Feed results of IPA-CP into value numbering

Hello Richi, it took me quite time to get back to this but it might have actually helped because it forced me to re-read the code around and in turn simplify the patch. On Mon, Jun 12 2023, Richard Biener wrote: > On Fri, 9 Jun 2023, Martin Jambor wrote: > [...] >> @@ -2327,7 +2330,7 @@ vn_walk

Re: [PATCH 0/3] fortran: fix length one character dummy args [PR110419]

Hi Mikael, Am 09.08.23 um 22:21 schrieb Mikael Morin via Gcc-patches: Hello, I propose with this patchset a fix for the test value_9.f90 which has been failing on 32 bits powerpc since it was added a few weeks back (see PR110360 and PR110419). The problem is an argument type mismatch between a

Re: [PATCH v1] RISC-V: Support RVV VFNMSUB rounding mode intrinsic API

LGTM juzhe.zh...@rivai.ai From: pan2.li Date: 2023-08-12 12:48 To: gcc-patches CC: juzhe.zhong; jeffreyalaw; pan2.li; yanzhang.wang; kito.cheng Subject: [PATCH v1] RISC-V: Support RVV VFNMSUB rounding mode intrinsic API From: Pan Li This patch would like to support the rounding mode API for

Re: [PATCH v1] RISC-V: Support RVV VFWMACC rounding mode intrinsic API

LGTm juzhe.zh...@rivai.ai From: pan2.li Date: 2023-08-13 16:02 To: gcc-patches CC: juzhe.zhong; pan2.li; yanzhang.wang; kito.cheng Subject: [PATCH v1] RISC-V: Support RVV VFWMACC rounding mode intrinsic API From: Pan Li This patch would like to support the rounding mode API for the VFWMACC

[pushed]LRA]: Fix asserts for output stack pointer reloads

The following patch fixes useless asserts in my latest patch implementing output stack pointer reloads. commit 18b417fe1a46d37738243267c1f559cd0acc4886 Author: Vladimir N. Makarov Date: Sun Aug 13 20:54:58 2023 -0400 [LRA]: Fix asserts for output stack pointer reloads The patch im

RE: [PATCH v1] RISC-V: Support RVV VFNMSUB rounding mode intrinsic API

Committed, thanks Juzhe. Pan From: juzhe.zh...@rivai.ai Sent: Monday, August 14, 2023 9:04 AM To: Li, Pan2 ; gcc-patches Cc: jeffreyalaw ; Li, Pan2 ; Wang, Yanzhang ; kito.cheng Subject: Re: [PATCH v1] RISC-V: Support RVV VFNMSUB rounding mode intrinsic API LGTM

RE: [PATCH v1] RISC-V: Support RVV VFWMACC rounding mode intrinsic API

Committed, thanks Juzhe. Pan From: juzhe.zh...@rivai.ai Sent: Monday, August 14, 2023 9:04 AM To: Li, Pan2 ; gcc-patches Cc: Li, Pan2 ; Wang, Yanzhang ; kito.cheng Subject: Re: [PATCH v1] RISC-V: Support RVV VFWMACC rounding mode intrinsic API LGTm juzhe.zh.

Re: [committed] Enable LRA on several ports

On Mon, 1 May 2023, Jeff Law wrote: > > Spurred by Segher's RFC, I went ahead and tested several ports with LRA > enabled. Not surprisingly, many failed, but a few built their full set of > libraries successful and of those a few even ran their testsuites with no > regressions. In fact, enablin

[committed] Disable LRA for MMIX.

Since the change r14-383-gfaf8bea79b6256 "Enable LRA on several ports", mmix has been broken building libstdc++-v3: libtool: compile: /obj/./gcc/xgcc -shared-libgcc -B/obj/./gcc -nostdinc++ -L/obj/mmix/libstdc++-v3/src -L/obj/mmix/libstdc++-v3/src/.libs -L/obj/mmix/libstdc++-v3/libsupc++/.libs -no

[committed] MMIX: Handle LRA FP-to-SP-elimination oddity

When LRA is in progress, it can try and validate insns half-way through frame-pointer (FP) to stack-pointer (SP) elimination. Operands have then been substituted where the offset is from the SP elimination but the register is the (hard) frame-pointer: lra-eliminations.cc:lra_eliminate_regs_1:370:

[PATCHv4, rs6000] Generate mfvsrwz for all subtargets and remove redundant zero extend [PR106769]

Hi, This patch modifies vsx extract expand and generates mfvsrwz/stxsiwx for all sub targets when the mode is V4SI and the extracted element is word 1 from BE order. Also this patch adds a insn pattern for mfvsrwz which helps eliminate redundant zero extend. Compared to last version, the main

[committed] MMIX: Re-enable LRA

After fixing the one problem for MMIX, there's just one test-case regressing between reload and LRA. -- 8< -- * config/mmix/mmix.cc: Re-enable LRA. --- gcc/config/mmix/mmix.cc | 3 --- 1 file changed, 3 deletions(-) diff --git a/gcc/config/mmix/mmix.cc b/gcc/config/mmix/mmix.cc index 51

[committed] MMIX: Switch to lra_in_progress

This is just a mechanical update. It fixes no observed problems for LRA. * config/mmix/predicates.md (mmix_address_operand): Use lra_in_progress, not reload_in_progress. --- gcc/config/mmix/predicates.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/gcc/confi

[PATCH v1] RISC-V: Support RVV VFWNMACC rounding mode intrinsic API

From: Pan Li This patch would like to support the rounding mode API for the VFWNMACC as the below samples. * __riscv_vfwnmacc_vv_f64m2_rm * __riscv_vfwnmacc_vv_f64m2_rm_m * __riscv_vfwnmacc_vf_f64m2_rm * __riscv_vfwnmacc_vf_f64m2_rm_m Signed-off-by: Pan Li gcc/ChangeLog: * config/ris

Re: [PATCH V2] Support -m[no-]gather -m[no-]scatter to enable/disable vectorization for all gather/scatter instructions

On Fri, Aug 11, 2023 at 2:02 PM liuhongt via Gcc-patches wrote: > > Rename original use_gather to use_gather_8parts, Support > -mtune-ctrl={,^}use_gather to set/clear tune features > use_gather_{2parts, 4parts, 8parts}. Support the new option -mgather > as alias of -mtune-ctrl=, use_gather, ^use_g

[PATCH] Generate vmovapd instead of vmovsd for moving DFmode between SSE_REGS.

vmovapd can enable register renaming and have same code size as vmovsd. Similar for vmovsh vs vmovaps, vmovaps is 1 byte less than vmovsh. When TARGET_AVX512VL is not available, still generate vmovsd/vmovss/vmovsh to avoid vmovapd/vmovaps zmm16-31. Bootstrapped and regtested on x86_64-pc-linux-gn

Re: [PATCH] Generate vmovapd instead of vmovsd for moving DFmode between SSE_REGS.

cc On Mon, Aug 14, 2023 at 10:46 AM liuhongt wrote: > > vmovapd can enable register renaming and have same code size as > vmovsd. Similar for vmovsh vs vmovaps, vmovaps is 1 byte less than > vmovsh. > > When TARGET_AVX512VL is not available, still generate > vmovsd/vmovss/vmovsh to avoid vmovapd/

[PATCH] RISC-V: Deduplicate #error messages in testsuite

From: Tsukasa OI "#error Feature macro not defined" is required to test the existence of an extension through the preprocessor. However, multiple occurrence of the exact same error message will confuse the developer once an error is encountered. This commit replaces such error messages to "#err

[PATCH v1] RISC-V: Support RVV VFWMSAC rounding mode intrinsic API

From: Pan Li This patch would like to support the rounding mode API for the VFWMSAC as the below samples. * __riscv_vfwmsac_vv_f64m2_rm * __riscv_vfwmsac_vv_f64m2_rm_m * __riscv_vfwmsac_vf_f64m2_rm * __riscv_vfwmsac_vf_f64m2_rm_m Signed-off-by: Pan Li gcc/ChangeLog: * config/riscv/ri

[PATCH v1 5/6] LoongArch: export headers for building GCC plugins

gcc/ChangeLog: * gcc/config/loongarch/t-loongarch: include loongarch-def.h, loongarch-tune.h and loongarch-driver.h in OPTIONS_H_EXTRA. Co-authored-by: Lulu Cheng --- gcc/config/loongarch/t-loongarch | 5 - 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/gcc/conf

[PATCH v1 3/6] LoongArch: define preprocessing macros "__loongarch_{arch, tune}"

These are exported according to the LoongArch Toolchain Conventions[1] as a replacement of the obsolete "_LOONGARCH_{ARCH,TUNE}" macros, which are expanded to strings representing the actual architecture and microarchitecture of the target. [1] currently relased at https://github.com/loongson/Loon

[PATCH v1 2/6] LoongArch: improved target configuration interface

The configure script and the GCC driver are updated so that it is easier to customize and control GCC builds for targeting different LoongArch implementations. * Support options for LoongArch SIMD extensions: new configure options --with-simd={none,lsx,lasx}; new driver options -m[no]-l[a]sx /

[PATCH v1 4/6] LoongArch: use -mstrict-align by default when building libraries

LoongArch processors may not support memory accesses without natural alignments. Building libraries with -mstrict-align may help with toolchain binary compatiblity and performance on these implementations (e.g. Loongson 2K1000LA). With this patch, no significant performance degredation is observe

[PATCH v1 6/6] LoongArch: support loongarch*-elf target

gcc/ChangeLog: * config.gcc: add loongarch*-elf target. * config/loongarch/elf.h: New file. Link against newlib by default. libgcc/ChangeLog: * config.host: add loongarch*-elf target. --- gcc/config.gcc | 21 --- gcc/config/loongarch/elf.h

[PATCH v1 1/6] LoongArch: a symmetric multilib subdir layout

Multilib in gcc is asymmetric. i.e. a "default" / "toplevel" library variant is always built and installed, and: * it is installed directly under the gcc libdir (with no suffix); * it is selected / searched / linked against when the gcc driver does not receive any option from MULTILIB_OPTIONS

[PATCH] x86: Update model values for Raptorlake.

Committed as obvious, and backported to GCC13. Lili. Update model values for Raptorlake according to SDM. gcc/ChangeLog * common/config/i386/cpuinfo.h (get_intel_cpu): Add model value 0xba to Raptorlake. --- gcc/common/config/i386/cpuinfo.h | 1 + 1 file changed, 1 insertion(+

Re: [PATCH v1 4/6] LoongArch: use -mstrict-align by default when building libraries

On Mon, 2023-08-14 at 11:57 +0800, Yang Yujie wrote: > LoongArch processors may not support memory accesses without natural > alignments.  Building libraries with -mstrict-align may help with > toolchain binary compatiblity and performance on these implementations > (e.g. Loongson 2K1000LA). I don

Re: [PATCH v1 2/6] LoongArch: improved target configuration interface

On Mon, 2023-08-14 at 11:57 +0800, Yang Yujie wrote: > The configure script and the GCC driver are updated so that > it is easier to customize and control GCC builds for targeting > different LoongArch implementations. > > * Support options for LoongArch SIMD extensions: >   new configure options

Re: [PATCH v1 3/6] LoongArch: define preprocessing macros "__loongarch_{arch,tune}"

On Mon, 2023-08-14 at 11:57 +0800, Yang Yujie wrote: > These are exported according to the LoongArch Toolchain Conventions[1] > as a replacement of the obsolete "_LOONGARCH_{ARCH,TUNE}" macros, > which are expanded to strings representing the actual architecture > and microarchitecture of the targe

Re: [PATCH v1 2/6] LoongArch: improved target configuration interface

On Mon, 2023-08-14 at 11:57 +0800, Yang Yujie wrote: > loongarch64) > -   tune_pattern="loongarch64|la464" > -   tune_default="la464" > +   tune_pattern="native|abi-default|loongarch64|la464" I think we can remove tune_pat

[PATCH 0/2] RISC-V: Make "prefetch.i" built-in usable

Hello, and... I think this might be my first *large* patch set for GCC contribution and definitely the first one to touch the machine description. So, please review it carefully. Background === This patch set adds an optimization to FP constant initialization using a FLI instruction, w

[PATCH 1/2] RISC-V: Add support for the 'Zfa' extension

From: Tsukasa OI This commit adds support for the 'Zfa' extension containing additional floating point instructions, version 0.1 (stable and approved). gcc/ChangeLog: * common/config/riscv/riscv-common.cc (riscv_implied_info): Add implication 'Zfa' -> 'F'. (riscv_ext_ver

[PATCH 2/2] RISC-V: Constant FP Optimization with 'Zfa'

From: Tsukasa OI This commit implements an optimization for assignments from a FP constant to a FP register using a FLI instruction from the 'Zfa' extension. To this purpose, it adds the constraint "H" and adds hardfloat move instructions a "H -> f" variant. Because FLI instruction constraint i

Re: [PATCH v1 1/6] LoongArch: a symmetric multilib subdir layout

On Mon, 2023-08-14 at 11:57 +0800, Yang Yujie wrote: > However, for LoongArch, we do not want such a "toplevel" library > installation since the default ABI may change. We expect all > multilib variants of libraries to be installed to their designated > ABI-specific subdirs (e.g. base/lp64d) of t

Re: [PATCH v1 1/6] LoongArch: a symmetric multilib subdir layout

On Mon, 2023-08-14 at 13:38 +0800, Xi Ruoyao wrote: > > > However, for LoongArch, we do not want such a "toplevel" library > > installation since the default ABI may change.  We expect all > > multilib variants of libraries to be installed to their designated > > ABI-specific subdirs (e.g. base/lp

[PATCH 1/2] light expander sra v0

Hi, There are a few PRs about the issues on the struct parameters and returns, like PRs 69143/65421/108073. we could consider introducing a light SRA in the expander to handle those parameters and returns in aggregate type, if they are passed through registers. For access to the fields of the pa

[PATCH 2/2] combine nonconstant_array walker and expander_sra walker

Hi, In the light-expander-sra, each statement in each basic-block of a function need to be analyzed, and there is a similar behavior in checking variable which need to be stored in the stack. These per-stmt analyses can be combined to improve cache locality. Bootstrapped and regtested on x86_64-

[PATCH v10] RISC-V: Add support for the Zfa extension

This patch adds the 'Zfa' extension for riscv, which is based on: https://github.com/riscv/riscv-isa-manual/commits/zfb The binutils-gdb for 'Zfa' extension: https://sourceware.org/pipermail/binutils/2023-April/127060.html What needs special explanation is: 1, According to riscv-spec, "The FCVTMO

Re: [PATCH v1 2/6] LoongArch: improved target configuration interface

On Mon, 2023-08-14 at 11:57 +0800, Yang Yujie wrote: > * Support options for LoongArch SIMD extensions: >   new configure options --with-simd={none,lsx,lasx}; >   new driver options -m[no]-l[a]sx / -msimd={none,lsx,lasx}. I suggest to rename --with-simd= to --with-ext= and accept a comma- separate

Re: [PATCH v9] RISC-V: Add the 'zfa' extension, version 0.2

> > Hi Jin Ma, > > > > On 5/16/23 00:06, jinma via Gcc-patches wrote: > > > On 5/15/23 07:16, Jin Ma wrote: > > >> > > >> Do we also need to check Z[FDH]INX too? > > >> > > >> Otherwise it looks pretty good. We just need to wait for everything to > > >> freeze and finalization on the assembler in

Re: [PATCH v1 2/6] LoongArch: improved target configuration interface

On Mon, 2023-08-14 at 13:58 +0800, Xi Ruoyao via Gcc-patches wrote: > On Mon, 2023-08-14 at 11:57 +0800, Yang Yujie wrote: > > * Support options for LoongArch SIMD extensions: > >   new configure options --with-simd={none,lsx,lasx}; > >   new driver options -m[no]-l[a]sx / -msimd={none,lsx,lasx}. >

[PATCH v1] RISC-V: Support RVV VFWNMSAC rounding mode intrinsic API

From: Pan Li This patch would like to support the rounding mode API for the VFWNMSAC as the below samples. * __riscv_vfwnmsac_vv_f64m2_rm * __riscv_vfwnmsac_vv_f64m2_rm_m * __riscv_vfwnmsac_vf_f64m2_rm * __riscv_vfwnmsac_vf_f64m2_rm_m Signed-off-by: Pan Li gcc/ChangeLog: * config/ris

Re: [PATCH v9] RISC-V: Add the 'zfa' extension, version 0.2

Additional links： v10, the patch that needs to be reviewed again: http://patchwork.ozlabs.org/project/gcc/patch/20230814055033.1995-1-ji...@linux.alibaba.com/ v9 and the previous review comments: http://patchwork.ozlabs.org/project/gcc/patch/20230515131628.953-1-ji...@linux.alibaba.com/ Zfa patch

[PATCH v2 0/3] RISC-V: Add stub support for existing extensions

PATCH v1: Changes: v1 -> v2 (only in PATCH 3/3) == Removed: 'Zvkn' -> 'Zvknha' implication (not to cause test failure) Added: 'Zfa' -> 'F' implication (just I forgot to add in PATCH v1) Th

[PATCH v2 3/3] RISC-V: Add stub support for existing extensions (unprivileged)

From: Tsukasa OI After commit c283c4774d1c ("RISC-V: Throw compilation error for unknown extensions") changed how do we handle unknown extensions, we have no guarantee that we can share the same architectural string with Binutils (specifically, the assembler). To avoid compilation errors on shar

[PATCH v2 1/3] RISC-V: Add stub support for existing extensions (privileged)

From: Tsukasa OI After commit c283c4774d1c ("RISC-V: Throw compilation error for unknown extensions") changed how do we handle unknown extensions, we have no guarantee that we can share the same architectural string with Binutils (specifically, the assembler). To avoid compilation errors on shar

[PATCH v2 2/3] RISC-V: Add stub support for existing extensions (vendor)

From: Tsukasa OI After commit c283c4774d1c ("RISC-V: Throw compilation error for unknown extensions") changed how do we handle unknown extensions, we have no guarantee that we can share the same architectural string with Binutils (specifically, the assembler). To avoid compilation errors on shar

Re: [PATCH 1/2] light expander sra v0

Hi, Jiufu Guo writes: > Hi, > > There are a few PRs about the issues on the struct parameters and > returns, like PRs 69143/65421/108073. > > we could consider introducing a light SRA in the expander to > handle those parameters and returns in aggregate type, if they > are passed through regis

Re: [PATCH v2 0/3] RISC-V: Add stub support for existing extensions

Hi, I'll explain a little more background. A major case which this patch set will be required is when a developer use inline assembly for instructions not yet natively supported by GCC or will not be supported as intrinsics. On such cases, GCC should at least accept corresponding extension via -

Re: [PATCH 0/2] RISC-V: Constant FP Optimization with 'Zfa'

Oh my, I forgot to change the subject of PATCH 0/2. That should have been "RISC-V: Constant FP Optimization with 'Zfa'", the same subject as PATCH 2/2. Sorry for confusion! On 2023/08/14 14:32, Tsukasa OI wrote: > Hello, > > and... I think this might be my first *large* patch set for GCC > contr

Re: [PATCH] rtl-optimization/110939 Really fix narrow comparison of memory and constant

On Sat, Aug 12, 2023 at 09:04:19AM +0800, Xi Ruoyao wrote: > On Thu, 2023-08-10 at 15:04 +0200, Stefan Schulze Frielinghaus via Gcc- > patches wrote: > > In the former fix in commit 41ef5a34161356817807be3a2e51fbdbe575ae85 I > > completely missed the fact that the normal form of a generated constan

Re: [PATCH v1] RISC-V: Support RVV VFWMSAC rounding mode intrinsic API

LGTM juzhe.zh...@rivai.ai From: pan2.li Date: 2023-08-14 11:29 To: gcc-patches CC: juzhe.zhong; pan2.li; yanzhang.wang; kito.cheng Subject: [PATCH v1] RISC-V: Support RVV VFWMSAC rounding mode intrinsic API From: Pan Li This patch would like to support the rounding mode API for the VFWMSAC

Re: [PATCH v1] RISC-V: Support RVV VFWNMSAC rounding mode intrinsic API

LGTM juzhe.zh...@rivai.ai From: pan2.li Date: 2023-08-14 14:07 To: gcc-patches CC: juzhe.zhong; pan2.li; yanzhang.wang; kito.cheng Subject: [PATCH v1] RISC-V: Support RVV VFWNMSAC rounding mode intrinsic API From: Pan Li This patch would like to support the rounding mode API for the VFWNMSA

[PATCH] VECT: Apply MASK_LEN_{LOAD_LANES, STORE_LANES} into vectorizer

From: Ju-Zhe Zhong Hi, Richard and Richi. This patch is adding MASK_LEN_{LOAD_LANES,STORE_LANES} support into vectorizer. Consider this simple case: void __attribute__ ((noinline, noclone)) foo (int *__restrict a, int *__restrict b, int *__restrict c, int *__restrict d, int *__restri

Re: [PATCH V4] VECT: Support loop len control on EXTRACT_LAST vectorization

On Fri, 11 Aug 2023, juzhe.zh...@rivai.ai wrote: > From: Ju-Zhe Zhong > > Hi, Richard and Richi. > > This patch add support live vectorization by VEC_EXTRACT for LEN loop control. OK. Thanks, Richard. > Consider this following case: > > #include > > #define EXTRACT_LAST(TYPE)