Re: [PATCH] RISC-V: Add 'bclr+binv' peephole2 optimization.

On 5/28/25 9:05 PM, Jiawei wrote: This seems like it would be much better as a combine pattern.   In fact, I'm a bit surprised that combine didn't simplify this series of operations into a IOR.  So I'd really like to see the .combine dump with and without this hunk for the relevant testcas

Re: [PATCH v5 02/24] i386: Add x86 FMV symbol tests

On 5/29/25 6:40 AM, Alfie Richards wrote: From: Alice Carlotti This is for testing the x86 mangling of FMV versioned function assembly names. gcc/testsuite/ChangeLog: * g++.target/i386/mv-symbols1.C: New test. * g++.target/i386/mv-symbols2.C: New test. * g++.target/

Re: [PATCH v5 01/24] ppc: Add PowerPC FMV symbol tests.

On 5/29/25 6:40 AM, Alfie Richards wrote: From: Alice Carlotti This tests the mangling of function assembly names when annotated with target_clones attributes. gcc/testsuite/ChangeLog: * g++.target/powerpc/mvc-symbols1.C: New test. * g++.target/powerpc/mvc-symbols2.C: New t

Re: [PATCH] RISC-V: Add 'bclr+binv' peephole2 optimization.

On 5/28/25 4:23 AM, Jiawei wrote: This patch adds a peephole2 optimization that combines a 'bclr' followed by a 'binv' into a single 'bset' instruction when the Zbs extension is enabled. The motivation for this patch is that PR116398 limits 2→2 RTL combinations, which prevents certain simplif

Re: [PATCH 0/3] Redirect to specific target based on TARGET_VERSION_COMPATIBLE

On 5/27/25 2:36 AM, Alfie Richards wrote: Hi Jeff, On 22/05/2025 21:02, Jeff Law wrote: On 5/22/25 9:05 AM, Alfie Richards wrote: Hi Jeff, I sent this patch with my implementation a while ago: https://gcc.gnu.org/pipermail/gcc-patches/2025-April/681043.html There hasn't bee

Re: [PATCH 0/3] Redirect to specific target based on TARGET_VERSION_COMPATIBLE

On 5/22/25 9:26 PM, Yangyu Chen wrote: On 23 May 2025, at 04:02, Jeff Law wrote: On 5/22/25 9:05 AM, Alfie Richards wrote: Hi Jeff, I sent this patch with my implementation a while ago: https://gcc.gnu.org/pipermail/gcc-patches/2025-April/681043.html There hasn't been any feedba

Re: [PATCH v1 1/3] RISC-V: Leverage vaadd.vv for signed standard name avg_floor

On 5/27/25 12:27 AM, Robin Dapp wrote: Apart from that it LGTM, thanks for digging deeper here. Just wanted to echo this. I've had a low priority todo to review vaaddu and friends after seeing them get used in some hand coded versions of various routines in x264. Even if you're not tackl

[to-be-committed][RISC-V] Add andi+bclr synthesis

So this patch from Shreya adds the ability to use andi + a series of bclr insns to synthesize a logical AND, much like we're doing for IOR/XOR using ori+bset or their xor equivalents. This would regress from a code quality standpoint if we didn't make some adjustments to a handful of define_in

[to-be-committed][RISC-V] shift+and+shift for logical and synthesis

The next chunk of Shreya's work. For this expansion we want to detect cases when the mask fits in a simm12 after shifting right by the number of trailing zeros in the mask. In that case we can synthesize the AND with a shift right, andi and shift left. I saw this case come up when doing some

Re: [PATCH 2/2] VR-VALUES: Rewrite test_for_singularity using range_op_handler

On 5/23/25 8:56 AM, Andrew MacLeod wrote: Since the PR scrolled by, i don't think I ever noticed this thread.. or at least where it lead. This is not an "equivalence" that ranger would propagate because its a relation with a constant. the issue here seems to be: if (x < 4)   when x has

Re: [PATCH 3/6] RISC-V: frm/mode-switch: remove dubious frm edge insertion before call_insn

On 5/22/25 6:12 AM, Robin Dapp wrote: AFAICT the main difference to standard mode switching is that we (ab)use it to set the rounding mode to the value it had initially, either at function entry or after a call.  That's different to regular mode switching which assumes "static" rounding mode

Re: [PATCH 0/3] Redirect to specific target based on TARGET_VERSION_COMPATIBLE

On 5/22/25 9:05 AM, Alfie Richards wrote: Hi Jeff, I sent this patch with my implementation a while ago: https://gcc.gnu.org/pipermail/gcc-patches/2025-April/681043.html There hasn't been any feedback on that patch yet. These patches are still useful and I would like to go ahead with them.

Re: [PATCH][RISC-V][PR target/70557] Improve storing 0 to memory on rv32

On 5/21/25 11:41 PM, Shreya Munnangi wrote: Patch is originally from Siarhei Volkau >. RISC-V has a zero register (x0) which we can use to store zero into memory without loading the constant into a distinct register. Adjust the constraints of the 32-bit movdi_32bit

Re: [PATCH] RISC-V: Add minimal support of double trap extension 1.0

On 5/22/25 12:21 AM, Jerry Zhang Jian wrote: Add support of double trap extension [1], enabling GCC to recognize the following extensions at compile time. New extensions: - ssdbltrp - smdbltrp [1] https://github.com/riscv/riscv-double-trap/releases/download/v1.0/riscv-double-trap.

Re: [PATCH] libgcc: PR target/116363 Fix SFtype to UDWtype conversion

On 5/22/25 1:01 AM, Jan Dubiec wrote: On 23.02.2025 04:59, Jeff Law wrote: [...] Thanks!  Just a note we're in stage4 of our development cycle (regression bugfixes) as we prepare for gcc-15.  This doesn't look like something we would typically make an exception for, it'll ha

Re: [PATCH] testsuite: RISC-V: Update the cset-sext-sfb/zba-slliuw test optimization level.

On 5/21/25 9:16 PM, Dongyan Chen wrote: Failed testcases occurred in the regression test of gcc: cset-sext-sfb.c failed the -Oz test, and zba-slliuw.c failed the -Og test. This patch solves the problem by skipping the optimization. gcc/testsuite/ChangeLog: * gcc.target/riscv/cset-sex

Re: [PATCH 0/3] Redirect to specific target based on TARGET_VERSION_COMPATIBLE

On 4/14/25 5:34 AM, Yangyu Chen wrote: On 14 Apr 2025, at 19:06, Alfie Richards wrote: Hi Yangyu, This looks great with what we discussed previously. I have a very similar patch that implements a slightly stronger optimisation that I was about to send. It makes use of information if th

Re: [PATCH] match: Undo maybe_push_res_to_seq in some cases [PR120331]

On 5/18/25 10:38 AM, Andrew Pinski wrote: While working on improving forwprop and removal of forward_propagate_into_gimple_cond/forward_propagate_into_comparison, I came cross a case where we end up with SSA_NAME in the resulting gimple_match_op and one statement in the sequence. This was the

[to-be-committed][RISC-V] Clear both upper and lower bits using 3 shifts

So the next step in Shreya's work. In the prior patch we used two shifts to clear bits at the high or low end of an object. In this patch we use 3 shifts to clear bits on both ends. Nothing really special here. With mvconst_internal still in the tree it's of marginal value, though Shreya an

Re: [PATCH 1/2] expand: Use rtx_cost directly instead of gen_move_insn for canonicalize_comparison.

On 5/20/25 9:12 PM, Andrew Pinski wrote: This is the first part in fixing PR target/120372. The current code for canonicalize_comparison, uses gen_move_insn and rtx_cost to find out the cost of generating a constant. This is ok in most cases except sometimes the comparison instruction can han

Re: [PATCH] configure: Always add pre-installed header directories to search path

On 9/25/24 9:22 PM, Stephanos Ioannidis wrote: configure script was adding the target directory flags, including the '-B' flags for the executable prefix and the '-isystem' flags for the pre-installed header directories, to the target flags only for non-Canadian builds under the premise that t

Re: [PATCH] combine: gen_lowpart_no_emit vs CLOBBER [PR120090]

On 5/21/25 4:29 PM, Andrew Pinski wrote: On Wed, May 21, 2025 at 3:21 PM Jeff Law wrote: On 5/5/25 3:27 PM, Andrew Pinski wrote: The problem here is simplify-rtx.cc expects gen_lowpart_no_emit to return NULL on failure but combine's hook was returning CLOBBER. After r1

Re: [PATCH] combine: gen_lowpart_no_emit vs CLOBBER [PR120090]

On 5/5/25 3:27 PM, Andrew Pinski wrote: The problem here is simplify-rtx.cc expects gen_lowpart_no_emit to return NULL on failure but combine's hook was returning CLOBBER. After r16-160-ge6f89d78c1a7528e93458278, gcc.target/i386/avx512bw-pr103750-2.c started to fail at -m32 due to this as new

[to-be-committed][RISC-V] Clear high or low bits using shift pairs

So the first special case of clearing bits from Shreya's work. We can clear an arbitrary number of high bits by shifting left by the number of bits to clear, then logically shifting right to put everything in place. Similarly we can clear an arbitrary number of low bits with a right logica

Re: [PATCH 3/6] RISC-V: frm/mode-switch: remove dubious frm edge insertion before call_insn

On 5/20/25 1:56 PM, Robin Dapp wrote: Maybe I'm missing something there.  Particularly whether or not you can know anything about frm's value after a call has returned. Normally the answer to this kind of question is a hard no. AFAICT the main difference to standard mode switching is that

[to-be-committed][RISC-V] Improve (x << C1) + C2 split code

I wrote this a couple months ago to fix an instruction count regression in 505.mcf on risc-v, but I don't have a trivial little testcase to add to the suite. There were two problems with the pattern. First, the code was generating a shift followed by an add after reload. Naturally combine doe

Re: [PATCH][RISC-V][PR target/70557] Improve storing 0 to memory on rv32

On 5/21/25 12:20 PM, Shreya Munnangi wrote: Patch is originally from Siarhei Volkau >. RISC-V has a zero register (x0) which we can use to store zero into memory without loading the constant into a distinct register. Adjust the constraints of the 32-bit movdi_32bit

Re: [PATCH V4] RISC-V: Prevent speculative vsetvl insn scheduling

On 5/20/25 4:05 PM, Edwin Lu wrote: The instruction scheduler appears to be speculatively hoisting vsetvl insns outside of their basic block without checking for data dependencies. This resulted in a situation where the following occurs vsetvli a5,a1,e32,m1,tu,ma vle32.v v2,

Re: [PATCH V4] RISC-V: Prevent speculative vsetvl insn scheduling

On 5/20/25 4:05 PM, Edwin Lu wrote: The instruction scheduler appears to be speculatively hoisting vsetvl insns outside of their basic block without checking for data dependencies. This resulted in a situation where the following occurs vsetvli a5,a1,e32,m1,tu,ma vle32.v v2,

Re: [PATCH 2/2] RISC-V:Add testcases for signed .SAT_ADD IMM form 1 with IMM = -1.

On 5/20/25 8:39 PM, Li, Pan2 wrote: Thanks Jeff. So for the tests, why are we forcing matching of the assembly code for the entire function? That must makes for a fragile test as we may change various aspects of code generation over time. If the point of the patch is to detect SAT_ADD in

[to-be-committed][RISC-V][PR target/120368] Fix 32bit shift on rv64

So a followup to last week's bugfix. In last week's change we we stopped using define_insn_and_split to rewrite instructions. That change was done to avoid dropping a masking instruction out of the RTL. As a result the pattern(s) were changed into simple define_insns, which is good. One of

Re: [PATCH 3/3] genemit: Use a byte encoding to generate insns

On 5/21/25 5:06 AM, Richard Sandiford wrote: Jeff Law writes: Given you know the RTL gen* related thingies better than anyone, I'd say go forward and if there's any fallout, we can certainly cope with it. Thanks. I've now pushed the series and the earlier genemit t

[to-be-committed][RISC-V] Infrastructure of synthesizing logical AND with constant

So this is the next step on the path to mvconst_internal removal and is work from Shreya and myself. This puts in the infrastructure to allow us to synthesize logical AND much like we're doing with logical IOR/XOR. Unlike IOR/XOR, AND has many more special cases that can be profitable. For e

Re: [PATCH] match: Remove valueize_condition argument from gimple_extra template

On 5/18/25 10:38 AM, Andrew Pinski wrote: After r15-4791-gb60031e8f9f8fe, the valueize_condition argument becomes unused. I didn't notice that as there was -Wno-unused option being added while compiling gimple-match-exports.cc. This removes that too as there are no unused warnings. gcc/Change

Re: [PATCH 3/3] genemit: Use a byte encoding to generate insns

On 5/18/25 2:41 PM, Richard Sandiford wrote: Target [A] [B] [C] native aarch64 0.5627 0.9585 0.5677 native x86_64 0.5925 0.9467 0.6377 aarch64-x-riscv64 0. 0.9066 0.2762 Nice. So how large

Re: [PATCH v2] driver: Fix multilib_os_dir and multiarch_dir for those target use TARGET_COMPUTE_MULTILIB

On 5/19/25 12:48 AM, Kito Cheng wrote: Hi Jin: Thanks for heads up:) Hi Jeff: I've rebased that on the trunk and everything seems right, do you think it's OK for the trunk? Yea, let's get it on the trunk and get it some soak time. We can then look at backporting it to gcc-15's release br

Re: [PATCH 2/2] RISC-V: Add testcases for signed vector SAT_ADD IMM form 1

On 5/19/25 2:42 AM, Li Xu wrote: From: xuli This patch adds testcase for form1, as shown below: void __attribute__((noinline)) \ vec_sat_s_add_imm_##T##_fmt_1##_##INDEX (T *out, T *op_1, unsigned limit) \ {

Re: [PATCH 2/2] RISC-V:Add testcases for signed .SAT_ADD IMM form 1 with IMM = -1.

On 5/19/25 2:41 AM, Li Xu wrote: From: xuli This patch adds testcase for form1, as shown below: T __attribute__((noinline)) \ sat_s_add_imm_##T##_fmt_1##_##INDEX (T x) \ {\ T sum = (UT)x + (UT)IMM;

Re: [PATCH v2 1/2] The following changes enable P8700 processor for RISCV and P8700 is a high-performance processor from MIPS by extending RISCV with custom instructions.

On 5/19/25 1:02 AM, Umesh Kalappa wrote: --- gcc/config/riscv/mips-p8700.md | 139 +++ gcc/config/riscv/riscv-cores.def | 5 ++ gcc/config/riscv/riscv-opts.h| 3 +- gcc/config/riscv/riscv.cc| 22 + gcc/config/riscv/riscv.md| 3

Re: [PATCH v2 2/2] MIPS p8700 doesn't have vector extension and added the dummies reservation for the same.

On 5/19/25 1:03 AM, Umesh Kalappa wrote: --- gcc/config/riscv/mips-p8700.md | 28 1 file changed, 28 insertions(+) I've pushed this to the trunk as well. Thanks, jeff

[committed][RISC-V][PR target/120333] Remove bogus bext pattern

execution test. Given it's a partial reversion and has passed in my tester, I'm going to go ahead and push it to the trunk rather than waiting for upstream CI. Jeff commit 38fa6c0455ec14f2f42310a817b90765ad894aa4 Author: Jeff Law Date: Mon May 19 16:55:15 2025 -0600 [committed]

Re: [to-be-committed][RISC-V] Avoid setting output object more than once in IOR/XOR synthesis

On 5/18/25 8:53 AM, Mark Wielaard wrote: Should output here be initialized to NULL_RTX? Yea, plus an assert to verify it's sensible after the two blobs of code that emit the [x]ori + bclr/binv sequences. I've pushed a fix to the trunk. jeff

[committed][RISC-V] Fix false positive from Wuninitialized

So this initializes OUTPUT and verifies it's got a reasonable value before using it for the final copy into operands[0]. Bootstrapped on the BPI (regression testing still has ~12hrs to go). Pushing to the trunk. Jeff commit cbc258cd318756db8b5f0e4055dd8f1c1d618d22 Author: Jeff Law Date: M

Re: [PATCH 6/9] genemit: Consistently use operand arrays in gen_* functions

On 5/19/25 3:16 AM, Richard Sandiford wrote: Richard Sandiford writes: Jeff Law writes: So two questions. Is there any meanginful performance impact expected here using the array form rather than locals? And does this impact how folks write their C/C++ fragments in the expanders and

Re: [PATCH 6/9] genemit: Consistently use operand arrays in gen_* functions

On 5/18/25 2:24 PM, Richard Sandiford wrote: gcc/ * genemit.cc (gen_rtx_scratch, gen_exp): Use operands[%d] rather than operand%d. (start_gen_insn): Store the incoming arguments to an operands array. (gen_expand, gen_split): Remove copies into and out of the o

Re: [PATCH 1/9] nds32: Avoid accessing beyond the operands[] array

On 5/18/25 2:19 PM, Richard Sandiford wrote: Jeff Law writes: On 5/16/25 11:32 AM, Jeff Law wrote: On 5/16/25 11:21 AM, Richard Sandiford wrote: This pattern used operands[2] to hold the shift amount, even though the pattern doesn't have an operand 2 (not even as a match_dup).

Re: [to-be-committed][RISC-V] Avoid setting output object more than once in IOR/XOR synthesis

On 5/18/25 8:53 AM, Mark Wielaard wrote: Hi Jeff, On Thu, May 15, 2025 at 10:11:19PM -0600, Jeff Law wrote: This has been tested in my tester and is currently bootstrapping on my BPI. Waiting on data from the pre-commit tester before moving forward... It looks like the Sourceware p550

[to-be-committed][RISC-V] Avoid multiple assignments to output object

This is the next batch of changes to reduce multiple assignments to an output object. This time I'm focused on splitters in bitmanip.md. This doesn't convert every case. For example there is one case that is very clearly dependent on eliminating mvconst_internal and adjustment of a splitter

Re: [PATCH 1/9] nds32: Avoid accessing beyond the operands[] array

On 5/16/25 11:32 AM, Jeff Law wrote: On 5/16/25 11:21 AM, Richard Sandiford wrote: This pattern used operands[2] to hold the shift amount, even though the pattern doesn't have an operand 2 (not even as a match_dup). This caused a build failure with -Werror:    array subscript 2 is

Re: [PATCH] ltmain.in: don't suppress output for PIC compilations

On 5/9/25 11:21 AM, Sam James wrote: Sam James writes: When working on xz, I set `-Werror=suggest-attribute=returns_nonnull`, and the build failed (as I expected it to), but with no visible error from the compiler. There's a mysterious '>/dev/null 2>&1' on the second line where liblzma_la-c

Re: [PATCH] libgcc SH: fix alignment for relaxation

On 5/10/25 11:12 AM, Quentin Boswank wrote: From 6462f1e6a2565c5d4756036d9bc2f39dce9bd768 Mon Sep 17 00:00:00 2001 From: QBos07 Date: Sat, 10 May 2025 16:56:28 + Subject: [PATCH] libgcc SH: fix alignment for relaxation when relaxation is enabled we can not infer the alignment from the p

Re: [PATCH v1 0/1]RISC-V :The following changes enable P8700 MIPS processor for RISC-V.

On 5/12/25 5:20 AM, Umesh Kalappa wrote: --- gcc/config/riscv/mips-p8700.md | 139 +++ gcc/config/riscv/riscv-cores.def | 5 ++ gcc/config/riscv/riscv-opts.h| 3 +- gcc/config/riscv/riscv.cc| 22 + gcc/config/riscv/riscv.md| 3

Re: [PATCH 2/6] RISC-V: frm/mode-switch: remove TARGET_MODE_CONFLUENCE

On 5/14/25 12:06 PM, Vineet Gupta wrote: On 5/13/25 10:07, Vineet Gupta wrote: On 5/10/25 07:20, Jeff Law wrote: On 5/9/25 2:27 PM, Vineet Gupta wrote: This is effectively reverting e5d1f538bb7d "(RISC-V: Allow different dynamic floating point mode to be merged)" while ret

Re: [PATCH 0/6] RISC-V: frm state-machine improvements

On 5/10/25 9:46 PM, Vineet Gupta wrote: Frankly I'm surprised we need FRM adjustments as much as we do, though presumably there's some builtin or somesuch that we need to twiddle FRM to implement and as a result if the builtin ever gets used it leads to FRM games. But it still seems high.

Re: [PATCH] gcc: add trigonometric pi-based functions as gcc builtins

On 5/14/25 2:22 PM, Joseph Myers wrote: On Wed, 14 May 2025, Yuao Ma wrote: Hi Joseph, I have updated the patch based on your review comments. I added the newly introduced builtin to extend.texi and mentioned the PR in the commit message. Could you please take another look when you have a m

Re: [PATCH] RISC-V: Add new operand constraint: cR

On 5/14/25 9:20 PM, Kito Cheng wrote: This commit introduces a new operand constraint `cR` for the RISC-V architecture, which allows the use of an even-odd RVC general purpose register (x8-x15) in inline asm. Ref: https://github.com/riscv-non-isa/riscv-c-api-doc/pull/102 gcc/ChangeLog:

Re: [PATCH] RISC-V: Support Zilsd code gen

On 5/14/25 9:14 PM, Kito Cheng wrote: This commit adds the code gen support for Zilsd, which is a newly added extension for RISC-V. The Zilsd extension allows for loading and storing 64-bit values using even-odd register pairs. We only try to do miminal code gen support for that, which means

[to-be-committed][RISC-V] Fix ICE due to bogus use of gen_rtvec

Found this while setting up the risc-v coordination branch off of gcc-15. Not sure why I didn't use rtvec_alloc directly here since we're going to initialize the whole vector ourselves. Using gen_rtvec was just wrong as it's walking down a non-existent varargs list. Under the "right" circums

Re: [PATCH 2/3] genemit: Avoid using gen_exp in output_add_clobbers

On 5/16/25 11:32 AM, Richard Sandiford wrote: output_add_clobbers emits code to add: (clobber (scratch:M)) and/or: (clobber (reg:M R)) expressions to the end of a PARALLEL. At the moment, it does this using the general gen_exp function. That makes sense with the code in its current

Re: [PATCH 1/3] genemit: Remove support for string operands

On 5/16/25 11:32 AM, Richard Sandiford wrote: gen_exp currently supports the 's' (string) operand type. It would certainly be possible to make the upcoming bytecode patch support that too. However, the rtx codes that have string operands should be very rarely used in hard-coded define_insn/e

Re: [PATCH 8/9] genemit: Always track multiple uses of operands

On 5/16/25 11:22 AM, Richard Sandiford wrote: gen_exp has code to detect when the same operand is used multiple times. It ensures that second and subsequent uses call copy_rtx, to enforce correct unsharing. However, for historical reasons that aren't clear to me, this was skipped for a defin

Re: [PATCH 6/9] genemit: Consistently use operand arrays in gen_* functions

On 5/16/25 11:21 AM, Richard Sandiford wrote: One slightly awkward part about emitting the generator function bodies is that: * define_insn and define_expand routines have a separate argument for each operand, named "operand0" upwards. * define_split and define_peephole2 routines take a p

Re: [PATCH 9/9] genemit: Remove purported handling of location_ts

On 5/16/25 11:22 AM, Richard Sandiford wrote: gen_exp had code to handle the 'L' operand format. But this format is specifically for location_ts, which are only used in RTX_INSNs. Those should never occur in this context, where the input is always an md file rather than an __RTL function. An

Re: [PATCH 7/9] genemit: Add a generator struct

On 5/16/25 11:22 AM, Richard Sandiford wrote: gen_exp now has quite a few arguments that need to be passed to each recursive call. This patch turns it and related routines into member functions of a new generator class, so that the shared information can be stored in member variables. This a

Re: [PATCH 5/9] genemit: Factor out code common to insns and expands

On 5/16/25 11:21 AM, Richard Sandiford wrote: Mostly to reduce cut-&-paste. gcc/ * genemit.cc (start_gen_insn): New function, split out from... (gen_insn, gen_expand): ...here. OK jeff

Re: [PATCH 4/9] genemit: Add an internal queue

On 5/16/25 11:21 AM, Richard Sandiford wrote: An earlier version of this series wanted to collect information about all the gen_* functions that are going to be generated. The current version no longer does that, but the queue seemed worth keeping anyway, since it gives a more consistent struc

Re: [PATCH 3/9] genemit: Use references rather than pointers

On 5/16/25 11:21 AM, Richard Sandiford wrote: This patch makes genemit.cc pass the md_rtx_info around by constant reference rather than pointer. It's somewhat of a cosmetic change on its own, but it makes later changes less noisy. gcc/ * genemit.cc (gen_exp): Make the info argument a

Re: [PATCH 1/9] nds32: Avoid accessing beyond the operands[] array

On 5/16/25 11:21 AM, Richard Sandiford wrote: This pattern used operands[2] to hold the shift amount, even though the pattern doesn't have an operand 2 (not even as a match_dup). This caused a build failure with -Werror: array subscript 2 is above array bounds of ‘rtx_def* [2]’ gcc/

Re: [PATCH 2/9] xstormy16: Avoid accessing beyond the operands[] array

On 5/16/25 11:21 AM, Richard Sandiford wrote: The negsi2 C++ code writes to operands[2] even though the pattern has no operand 2. gcc/ * config/stormy16/stormy16.md (negsi2): Remove unused assignment. Also obviously OK. jeff

Re: [PATCH] RISC-V: Since the loop increment i++ is unreachable, the loop body will never execute more than once

On 5/16/25 1:32 AM, Jin Ma wrote: Reported-by: huangcunjian gcc/ChangeLog: * config/riscv/riscv.cc (riscv_gpr_save_operation_p): Remove break and fixbug for elt index. Ideally we'd have a testcase for whatever issue motivated this change, but it's pretty clear that the elem

Re: [PATCH v1] RISC-V: Avoid scalar unsigned SAT_ADD test data duplication

On 5/16/25 2:38 AM, pan2...@intel.com wrote: From: Pan Li Some of the previous scalar unsigned SAT_ADD test data are duplicated in different test files. This patch would like to move them into a shared header file, to avoid the test data duplication. The below test suites are passed for th

[to-be-committed][RISC-V] Avoid setting output object more than once in IOR/XOR synthesis

While evaluating Shreya's logical AND synthesis work on spec2017 I ran into a code quality regression where combine was failing to eliminate a redundant sign extension. I had a hunch the problem would be with the multiple sets of the same pseudo register in the AND synthesis path. I was right

Re: [PATCH] RISC-V: Fix the warning of temporary object dangling references.

On 5/15/25 8:35 PM, Kito Cheng wrote: Hm, it really doesn't make too much sense to get that warning, but I can reproduce that when I compile with gcc 13 (and newer)...and seems like a known issue [1][2]... I still hadn't managed to convince myself the code was wrong. It looked more like

Re: [PATCH 1/4] Make end_sequence return the insn sequence

On 5/15/25 11:18 AM, Richard Sandiford wrote: The start_sequence/end_sequence interface was a big improvement over the previous state, but one slightly awkward thing about it is that you have to call get_insns before end_sequence in order to get the insn sequence itself: I can't even remember

Re: [PING][PATCH][GCC15] Alpha: Fix base block alignment calculation regression

On 5/12/25 11:21 AM, Maciej W. Rozycki wrote: On Tue, 25 Feb 2025, Maciej W. Rozycki wrote: Address this issue by recursing into COMPONENT_REF tree nodes until the outermost one has been reached, which is supposed to be a MEM_REF one, accumulating the offset as we go, fixing a commit e0dae4d

Re: [PATCH] RISC-V: Fix uninit riscv_subset_list::m_allow_adding_dup issue

On 5/12/25 8:34 PM, Kito Cheng wrote: We forgot to initialize m_allow_adding_dup in the constructor of riscv_subset_list, then that will be a random value...that will lead to a random behavior of the -march may accpet duplicate extension. gcc/ChangeLog: * common/config/riscv/riscv-co

[to-be-committed][RISC-V][PR target/120223] Don't use bset/binv for XTHEADBS

Thead has the XTHEADBB extension which has a lot of overlap with Zbb. I made the incorrect assumption that XTHEADBS would largely be like Zbs when generalizing Shreya's work. As a result we can't use the operation synthesis code for IOR/XOR because we don't have binv/bset like capabilities.

Re: [PATCH 3/6] RISC-V: frm/mode-switch: remove dubious frm edge insertion before call_insn

On 5/12/25 4:17 PM, Vineet Gupta wrote: On 5/12/25 14:55, Jeff Law wrote: test_float_point_frm_static: 1: frrma5 <-- 2: fsrmi 2 3: fsrma5 <-- 4: callnormalize_vl 5: frrma5 <-- 6:

Re: [PATCH 3/6] RISC-V: frm/mode-switch: remove dubious frm edge insertion before call_insn

On 5/10/25 9:55 PM, Vineet Gupta wrote: On 5/10/25 07:17, Jeff Law wrote: On 5/9/25 2:27 PM, Vineet Gupta wrote: This showed up when debugging the testcase for PR119164. RISC-V FRM mode-switching state machine has special handling for transitions to and from a call_insn as FRM needs to

Re: [PATCH v4 1/2] RISC-V: Support RISC-V Profiles 20/22.

On 5/10/25 6:30 AM, Jiawei wrote: This patch introduces support for RISC-V Profiles RV20 and RV22 [1], enabling developers to utilize these profiles through the -march option. [1] https://github.com/riscv/riscv-profiles/releases/tag/v1.0 Version log: Using lowercase letters to present Profil

Re: [PATCH 1/6] emit-rtl: document next_nonnote_nondebug_insn_bb () can breach into next BB

On 5/9/25 2:27 PM, Vineet Gupta wrote: gcc/ChangeLog: * emit-rtl.cc (next_nonnote_nondebug_insn): Update comments. Signed-off-by: Vineet Gupta --- gcc/emit-rtl.cc | 6 +- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/gcc/emit-rtl.cc b/gcc/emit-rtl.cc index 3e2c

Re: [PATCH 4/6] RISC-V: frm/mode-switch: TARGET_MODE_AFTER not needed for frm switching

On 5/9/25 2:27 PM, Vineet Gupta wrote: Stumbled upon this when trying to wholesale rewrite frm switching code and seeing what pieces needed to be retained from current implementation. My interpretation of how this hook worked, for the following case: fsrmi 3 fsrm a4 call

Re: [PATCH 3/6] RISC-V: frm/mode-switch: remove dubious frm edge insertion before call_insn

On 5/9/25 2:27 PM, Vineet Gupta wrote: This showed up when debugging the testcase for PR119164. RISC-V FRM mode-switching state machine has special handling for transitions to and from a call_insn as FRM needs to saved/restored around calls (any call is considered potentially FRM clobbering).

Re: [PATCH 2/6] RISC-V: frm/mode-switch: remove TARGET_MODE_CONFLUENCE

On 5/9/25 2:27 PM, Vineet Gupta wrote: This is effectively reverting e5d1f538bb7d "(RISC-V: Allow different dynamic floating point mode to be merged)" while retaining the testcase. The change itself is valid, however it obfuscates the deficiencies in current frm mode switching code. Also for

Re: [PATCH 0/6] RISC-V: frm state-machine improvements

On 5/9/25 2:27 PM, Vineet Gupta wrote: Hi, This came out of Rivos perf team reporting (shoutout to Siavash) that some of the SPEC2017 workloads had unnecessary FRM wiggles, when none were needed. The writes in particular could be expensive. I started with reduced test for PR/119164 from blen

Re: [PATCH v2] RISC-V: Use vclmul for CRC expansion if available

On 5/9/25 4:09 AM, Anton Blanchard wrote: If the vector version of clmul (vclmul) is available and the scalar one is not, use it for CRC expansion. gcc/Changelog: * config/riscv/bitmanip.md (crc_rev4): Check TARGET_ZVBC. (crc4): Likewise. * config/riscv/riscv.

[to-be-committed][V2][RISC-V] Synthesize more efficient IOR/XOR sequences

Bah! I hand-edited the patch to fix some missing HOST_WIDE_INT_UC macros I saw and botched it. While I was at it, I fixed various lint issues. No functional changes though. -- So mvconst_internal's primary benefit is in constant synthesis not impacting the combine budget in terms of the nu

[to-be-committed][RISC-V] Synthesize more efficient IOR/XOR sequences

This is Shreya's next packet of work -- infrastructure for removing mvconst_internal which would ultimately make Vineet happier :-) -- So mvconst_internal's primary benefit is in constant synthesis not impacting the combine budget in terms of the number of instructions it is willing to comb

Re: [PATCH] RISC-V: Minimal support for zama16b extension.

On 4/18/25 2:46 AM, Dongyan Chen wrote: This patch support zama16b extension[1]. To enable GCC to recognize and process zama16b extension correctly at compile time. [1] https://github.com/riscv/riscv-profiles/blob/main/src/rva23-profile.adoc gcc/ChangeLog: * common/config/riscv/ris

[to-be-committed][RISC-V][PR target/120137] Don't create out-of-range permutation constants

To make hashing sensible we canonicalize constant vectors in the hash table so that their first entry always has the value zero. That normalization can result in a value that can't be represented in the element mode. So before entering anything into the hash table we need to verify the nor

Re: [PATCH] RISC-V: Minimal support for sdtrig and ssstrict extensions.

On 4/18/25 2:47 AM, Dongyan Chen wrote: This patch support sdtrig and ssstrict extensions[1]. To enable GCC to recognize and process sdtrig and ssstrict extensions correctly at compile time. [1]https://github.com/riscv/riscv-profiles/blob/main/src/rva23-profile.adoc gcc/ChangeLog:

Re: [PATCH] RISC-V: Recognized svadu and svade extension

On 3/24/25 6:18 AM, Mingzhu Yan wrote: This patch support svadu and svade extension. To enable GCC to recognize and process svadu and svade extension correctly at compile time. gcc/ChangeLog: * common/config/riscv/riscv-common.cc: (riscv_ext_version_table) New extension.

[to-be-committed][RISC-V] Avoid unnecessary andi with -1 argument

I was preparing to do some testing of Shreya's next patch on spec and stumbled across another "andi dst,src,-1" case. I fixed some stuff like this in the gcc-15 cycle, but this one slipped through. It's probably about 100M instructions on deepsjeng. So tiny, but there's no good reason to lea

Re: [PATCH v2] RISC-V: Support for zilsd and zclsd extensions.

On 3/17/25 8:26 AM, Dongyan Chen wrote: This patch support zilsd and zclsd[1] extensions. To enable GCC to recognize and process zilsd and zclsd extension correctly at compile time. [1] https://github.com/riscv/riscv-zilsd Changes for v2: - Remove the addition of zilsd and zclsd extension i

Re: [PATCH] RISC-V: Add pattern for vector-scalar multiply-add/sub [PR119100]

On 4/16/25 8:32 AM, Paul-Antoine Arras wrote: Please find attached an updated patch with an additional cost model. By default, an instruction is 4 and the penalty for moving data from floating-point to vector register is 2; thus, vfmadd.vf costs 6, which still makes it cheaper than vec_du

[to-be-committed][RISC-V][PR middle-end/114512] Recognize more bext idioms for RISC-V

This is Shreya's next chunk of work. When I was looking for good bugs for her to chase down I cam across PR114512. While the bug isn't necessarily a RISC-V specific bug, its testcases did show how we were failing to recognize certain bit extraction idioms and how the lispy nature of RTL allow

[RISC-V][PR target/119971] Avoid losing shift count masking

ommit 05d75c5bfcf923bc0258b79a08c5861590c5a2b9 Author: Jeff Law Date: Mon May 5 17:14:29 2025 -0600 [RISC-V][PR target/119971] Avoid losing shift count masking As is outlined in the PR, we have a few define_insn_and_split patterns which optimize away explicit masking of shift/bit positions whe

[to-be-committed][RISC-V][PR target/119971] Avoid losing shift count masking

As is outlined in the PR, we have a few define_insn_and_split patterns which optimize away explicit masking of shift/bit positions when the masking matches what the hardware's behavior. A small number of those define_insn_and_split patterns generate a single instruction. It's fairly elegant i

Re: [PATCH] RISC-V: Fix gcc.target/riscv/predef-19.c [PR120054]

On 5/4/25 8:13 PM, Kito Cheng wrote: gcc/testsuite/ChangeLog: PR target/120054 * gcc.target/riscv/predef-19.c: Adjust testcase. If you think it's right fix, then OK. I haven't dove into it at all. Just want to see it get fixed so the CI/testers are happy again :-) jeff

Re: [PATCH] RISC-V: Use vclmul for CRC expansion if available

On 5/4/25 10:49 PM, Anton Blanchard wrote: If the vector version of clmul (vclmul) is available and the scalar one is not, use it for CRC expansion. gcc/Changelog: * config/riscv/bitmanip.md (crc_rev4): Check TARGET_ZVBC. (crc4): Likewise. * config/riscv/riscv

  1   2   3   4   5   6   7   8   9   10   >