[gcc(refs/vendors/riscv/heads/gcc-14-with-riscv-opts)] This is almost exclusively Jivan's work. His original post:

https://gcc.gnu.org/g:ece3a7538a6414d13dc2ac92c6e88fe7c203fcd1 commit ece3a7538a6414d13dc2ac92c6e88fe7c203fcd1 Author: Jivan Hakobyan Date: Tue Apr 30 09:44:02 2024 -0600 This is almost exclusively Jivan's work. His original post: >

[gcc(refs/vendors/riscv/heads/gcc-14-with-riscv-opts)] RISC-V: Refine the condition for add additional vars in RVV cost model

https://gcc.gnu.org/g:5009e02a5d556fac7d0b56e3c3614427332502d5 commit 5009e02a5d556fac7d0b56e3c3614427332502d5 Author: demin.han Date: Tue Mar 26 16:52:12 2024 +0800 RISC-V: Refine the condition for add additional vars in RVV cost model The adjacent_dr_p is sufficient and

[gcc(refs/vendors/riscv/heads/gcc-14-with-riscv-opts)] RISC-V: Fix parsing of Zic* extensions

https://gcc.gnu.org/g:7cae85835c5b6a5bb3231efc0121073f5054c26f commit 7cae85835c5b6a5bb3231efc0121073f5054c26f Author: Christoph Müllner Date: Mon Apr 29 00:46:06 2024 +0200 RISC-V: Fix parsing of Zic* extensions The extension parsing table entries for a range of Zic* extensions

[gcc(refs/vendors/riscv/heads/gcc-14-with-riscv-opts)] RISC-V: Add -X to link spec

https://gcc.gnu.org/g:355f858c80fbdd3b4c67002e9685631fd10a6641 commit 355f858c80fbdd3b4c67002e9685631fd10a6641 Author: Fangrui Song Date: Fri Apr 26 18:14:33 2024 -0700 RISC-V: Add -X to link spec --discard-locals (-X) instructs the linker to remove local .L* symbols, which

[committed] [RISC-V] Improve floor, ceil & related operations for RISC-V

This is almost exclusively Jivan's work. His original post: https://www.mail-archive.com/gcc-patches@gcc.gnu.org/msg336483.html This patch is primarily meant to improve the code we generate for FP rounding such as ceil/floor. It also addresses some unnecessary sign extensions in the

[gcc r15-71] This is almost exclusively Jivan's work. His original post:

https://gcc.gnu.org/g:f652a35877e32d470d649d1aee5d94fa0169a478 commit r15-71-gf652a35877e32d470d649d1aee5d94fa0169a478 Author: Jivan Hakobyan Date: Tue Apr 30 09:44:02 2024 -0600 This is almost exclusively Jivan's work. His original post: >

[gcc] Created branch 'riscv/heads/gcc-14-with-riscv-opts' in namespace 'refs/vendors'

The branch 'riscv/heads/gcc-14-with-riscv-opts' was created in namespace 'refs/vendors' pointing to: 7a00c459cbb... libstdc++: Do not apply localized formatting to NaN and inf

Re: [PATCH] Remove m_nloops field from loop_versioning

On 4/26/24 11:25 PM, Andrew Pinski wrote: This is a small cleanup of loop_versioning where m_nloops is only used in the constructor so we can remove the whole field. Bootstrapped and tested on x86_64-linux-gnu. gcc/ChangeLog: * gimple-loop-versioning.cc (loop_versioning): Remove

Re: [PATCH v2] DSE: Bugfix ICE after allow vector type in get_stored_val

On 3/22/24 11:45 PM, Li, Pan2 wrote: Thanks Jeff for comments. As Richi noted using validate_subreg here isn't great. Does it work to factor out this code from extract_low_bits if (!int_mode_for_mode (src_mode).exists (_int_mode) || !int_mode_for_mode (mode).exists (_mode))

Re: [PATCH] Minor tweaks to code computing modular multiplicative inverse

On 4/29/24 1:14 AM, Eric Botcazou wrote: Hi, this removes the last parameter of choose_multiplier, which is unused, adds another assertion and more details to the description and various comments. Likewise to the closely related invert_mod2n, except for the last parameter. Tested on

Re: [PATCH v1] RISC-V: Revert RVV wv instructions overlap and xfail tests

On 4/22/24 4:07 PM, 钟居哲 wrote: Apologize that we didn't post our (me, kito and Li Pan) disscussions. This is the story: We found that my previous patches which support highpart register overlap with register filter for instructions like (vwadd.wv) cause ICE reported by:

Re: Deprecation/removal of nios2 target support

On 4/18/24 9:57 AM, Joel Sherrill wrote: On Thu, Apr 18, 2024 at 10:46 AM Joseph Myers > wrote: On Wed, 17 Apr 2024, Sandra Loosemore wrote: > Therefore I'd like to mark Nios II as obsolete in GCC 14 now, and remove > support from all

Re: [PATCH] [RISC-V] optimize Zicond conditional select cases.

On 4/15/24 7:27 PM, Fei Gao wrote: On 2024-04-15 21:04  Jeff Law wrote: On 4/15/24 6:58 AM, Kito Cheng wrote: It's simple enough, so LGTM for trunk :) We're already doing this internally.  I just hadn't submitted it due to being deep into stage4. Jeff Hi Jeff Would you like me

Re: [PATCH] m68k: Quiet up cppcheck warning [PR114689]

On 4/15/24 8:43 AM, Jakub Jelinek wrote: Hi! cppcheck apparently warns on the | !!sticky part of the expression and using | (!!sticky) quiets it up (it is correct as is). The following patch adds the ()s, and also adds them around mant >> 1 just in case it makes it clearer to all readers

Re: [PATCH] [RISC-V] optimize Zicond conditional select cases.

On 4/15/24 6:58 AM, Kito Cheng wrote: It's simple enough, so LGTM for trunk :) We're already doing this internally. I just hadn't submitted it due to being deep into stage4. Jeff

Re: [PATCH/RFC] On the use of -funreachable-traps to deal with PR 109627

On 4/8/24 5:04 PM, Iain Sandoe wrote: Hi PR 109627 is about functions that have had their bodies completely elided, but still have the wrappers for EH frames (either .cfi_xxx or LFSxx/LFExx). These are causing issues for some linkers because such functions result in FDEs with a 0 code

Re: [PATCH v3] RISC-V: Replace zero_extendsidi2_shifted with generalized split

On 3/27/24 4:55 AM, Philipp Tomsich wrote: Jeff, just a heads-up that that trunk (i.e., the soon-to-be GCC14) still generates the suboptimal sequence: https://godbolt.org/z/K9YYEPsvY Realistically it's too late to get this into gcc-14. Jeff

Re: [PATCH] rtl-optimization/101523 - avoid re-combine after noop 2->2 combination

On 4/5/24 3:27 PM, Segher Boessenkool wrote: Hi! On Wed, Apr 03, 2024 at 01:07:41PM +0200, Richard Biener wrote: The following avoids re-walking and re-combining the instructions between i2 and i3 when the pattern of i2 doesn't change. Bootstrap and regtest running ontop of a reversal of

Re: [PATCH] middle-end/114579 - speed up add_scope_conflicts

On 4/4/24 6:41 AM, Richard Biener wrote: The following speeds up stack variable conflict detection by recognizing that the all-to-all conflict recording is only necessary for CFG merges as it's the unioning of the live variable sets that doesn't come with explicit mentions we record conflicts

Re: Sourceware mitigating and preventing the next xz-backdoor

On 4/3/24 8:04 AM, Tom Tromey wrote: "Florian" == Florian Weimer writes: Florian> Everyone still pushes their own patches, and there are no Florian> technical countermeasures in place to ensure that the pushed version is Florian> the reviewed version. This is a problem for gdb as well.

[committed] RISC-V: Add missing insn types to XiangShan Nanhu scheduler model

to ensure that all insn types map to an insn reservation. Pushing this to the trunk. Jeff commit 08eaafadd5beaa56beb2d1fceca9f97eeb0219ba Author: Jeff Law Date: Sun Mar 31 10:51:17 2024 -0600 [committed] RISC-V: Add missing insn types to XiangShan Nanhu scheduler model The test

[gcc r14-9732] [committed] RISC-V: Add missing insn types to XiangShan Nanhu scheduler model

https://gcc.gnu.org/g:08eaafadd5beaa56beb2d1fceca9f97eeb0219ba commit r14-9732-g08eaafadd5beaa56beb2d1fceca9f97eeb0219ba Author: Jeff Law Date: Sun Mar 31 10:51:17 2024 -0600 [committed] RISC-V: Add missing insn types to XiangShan Nanhu scheduler model The test for the recently

[committed] Provide suitable output template for zero_extendqihi2 on H8

ble output template for the reg->reg case. Regression tested on h8300-elf. Pushing to the trunk. gcc/ * config/h8300/extensions.md (zero_extendqihi*): Add output template for reg->reg case where the regs don't match. Jeffcommit c1e66532cbb424bd7ea8c3b2c1ffea4bb5233309 Aut

[gcc r14-9715] [committed] Provide suitable output template for zero_extendqihi2 on H8

https://gcc.gnu.org/g:c1e66532cbb424bd7ea8c3b2c1ffea4bb5233309 commit r14-9715-gc1e66532cbb424bd7ea8c3b2c1ffea4bb5233309 Author: Jeff Law Date: Thu Mar 28 16:56:53 2024 -0600 [committed] Provide suitable output template for zero_extendqihi2 on H8 Segher's recent combine change

Re: [PATCH] RISC-V: Refine the condition for add additional vars in RVV cost model

On 3/28/24 4:31 AM, demin.han wrote: The adjacent_dr_p is sufficient and unnecessary condition for contiguous access. So unnecessary live-ranges are added and result in spill. This patch uses MEMORY_ACCESS_TYPE as condition and constrains segment load/store. Tested on RV64 and no

Re: [PATCH] RISC-V: testsuite: ensure vtype is call clobbered

On 3/27/24 4:14 PM, Vineet Gupta wrote: Per classic Vector calling convention ABI, vtype is call clobbered, so ensure gcc generates fresh a VSETVLI after a function call or an inline asm which clobbers vtype. ATM gcc seems to be doing the right thing, but a test can never be harmful.

Re: TARGET_RTX_COSTS and pipeline latency vs. variable-latency instructions (was Re: [PATCH] RISC-V: Add XiangShan Nanhu microarchitecture.)

On 3/25/24 2:57 PM, Palmer Dabbelt wrote: On Mon, 25 Mar 2024 13:49:18 PDT (-0700), jeffreya...@gmail.com wrote: On 3/25/24 2:31 PM, Palmer Dabbelt wrote: On Mon, 25 Mar 2024 13:27:34 PDT (-0700), Jeff Law wrote: I'd doubt it's worth the complexity.  Picking some reasonable value gets

Re: TARGET_RTX_COSTS and pipeline latency vs. variable-latency instructions (was Re: [PATCH] RISC-V: Add XiangShan Nanhu microarchitecture.)

On 3/25/24 2:31 PM, Palmer Dabbelt wrote: On Mon, 25 Mar 2024 13:27:34 PDT (-0700), Jeff Law wrote: I'd doubt it's worth the complexity.  Picking some reasonable value gets you the vast majority of the benefit.   Something like COSTS_N_INSNS(6) is enough to get CSE to trigger.  So what's

Re: TARGET_RTX_COSTS and pipeline latency vs. variable-latency instructions (was Re: [PATCH] RISC-V: Add XiangShan Nanhu microarchitecture.)

On 3/25/24 2:13 PM, Palmer Dabbelt wrote: On Mon, 25 Mar 2024 12:59:14 PDT (-0700), Jeff Law wrote: On 3/25/24 1:48 PM, Xi Ruoyao wrote: On Mon, 2024-03-18 at 20:54 -0600, Jeff Law wrote: +/* Costs to use when optimizing for xiangshan nanhu.  */ +static const struct riscv_tune_param

Re: TARGET_RTX_COSTS and pipeline latency vs. variable-latency instructions (was Re: [PATCH] RISC-V: Add XiangShan Nanhu microarchitecture.)

On 3/25/24 1:48 PM, Xi Ruoyao wrote: On Mon, 2024-03-18 at 20:54 -0600, Jeff Law wrote: +/* Costs to use when optimizing for xiangshan nanhu.  */ +static const struct riscv_tune_param xiangshan_nanhu_tune_info = { +  {COSTS_N_INSNS (3), COSTS_N_INSNS (3)}, /* fp_add */ +  {COSTS_N_INSNS

Re: scheduler queue flush (was Re: [gcc-15 0/3] RISC-V improve stack/array access by constant mat tweak)

On 3/21/24 11:19 AM, Vineet Gupta wrote: Oh yeah ! Robin hinted to this in Tues patchworks meeting too default : 2,565,319,368,591 128 : 2,509,741,035,068 256 : 2,527,817,813,612 no-sched{,2}: 1,295,520,567,376 So one more nugget here. I happened to be doing some

Re: [gcc-15 2/3] RISC-V: avoid LUI based const mat: keep stack offsets aligned

On 3/19/24 2:05 PM, Vineet Gupta wrote: On 3/19/24 06:10, Jeff Law wrote: On 3/19/24 12:48 AM, Andrew Waterman wrote: On Mon, Mar 18, 2024 at 5:28 PM Vineet Gupta wrote: On 3/16/24 13:21, Jeff Law wrote: | 59944:add s0,sp,2047 < | 59948:mv a2,a0 | 59

Re: [gcc-15 1/3] RISC-V: avoid LUI based const materialization ... [part of PR/106265]

On 3/18/24 6:07 PM, Vineet Gupta wrote: Naive question: why is define_split more natural vs. define_insn_and_split. Is it because of the syntax/implementation or that one is more Combine "centric" and other is more of a Split* Pass thing (roughly speaking of course) or something else

Re: [PATCH] RISC-V: Add initial cost handling for segment loads/stores.

On 3/1/24 8:07 AM, Robin Dapp wrote: +  /* Segment load/store permute cost.  */ +  const int segment_permute_2; +  const int segment_permute_4; +  const int segment_permute_8; Why do we only have 2/4/8, I think we should have 2/3/4/5/6/7/8 No idea why I posted that (wrong) version, I used

Re: New effective-target 'asm_goto_with_outputs'

On 3/22/24 12:24 PM, Jakub Jelinek wrote: On Fri, Mar 22, 2024 at 12:17:03PM -0600, Jeff Law wrote: I'd just make target_lra return false for nvptx rather than creating a new The lra effective target currently though doesn't check if asm goto can have outputs, but rather if the target

Re: [PATCH v2] DSE: Bugfix ICE after allow vector type in get_stored_val

On 3/4/24 11:22 PM, Li, Pan2 wrote: Thanks Jeff for comments. But in the case of a vector modes, we can usually reinterpret the underlying bits in whatever mode we want and do any of the usual operations on those bits. Yes, I think that is why we can allow vector mode in get_stored_val if

Re: New effective-target 'asm_goto_with_outputs'

On 3/21/24 5:20 AM, Thomas Schwinge wrote: Hi! On 2024-02-16T10:48:53-0800, Mike Stump wrote: On Feb 16, 2024, at 2:16 AM, Jakub Jelinek wrote: There is one special case, NVPTX, which is a TARGET_NO_REGISTER_ALLOCATION target. I think claiming for it that it is a lra target is strange

Re: [PATCH] [tree-prof] skip if errors were seen [PR113681]

On 3/9/24 2:11 AM, Alexandre Oliva wrote: ipa_tree_profile asserts that the symtab is in IPA_SSA state, but we don't reach that state and ICE if e.g. ipa-strub passes report errors. Skip this pass if errors were seen. Regstrapped on x86_64-linux-gnu. Ok to install? for gcc/ChangeLog

Re: [PATCH] handle unwind tables that are embedded within unwinding code, [PR111731]

On 3/15/24 4:29 AM, Thomas Neumann wrote: Original bug report: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111731 Given that this is a regression, is this okay for gcc 13 and mainline? The unwinding mechanism registers both the code range and the unwind table itself within a b-tree lookup

Re: [PATCH] handle unwind tables that are embedded within unwinding code, [PR111731]

On 3/15/24 4:29 AM, Thomas Neumann wrote: Original bug report: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111731 Given that this is a regression, is this okay for gcc 13 and mainline? The unwinding mechanism registers both the code range and the unwind table itself within a b-tree lookup

Re: scheduler queue flush (was Re: [gcc-15 0/3] RISC-V improve stack/array access by constant mat tweak)

On 3/22/24 2:47 AM, Richard Biener wrote: On Thu, Mar 21, 2024 at 8:56 PM Jeff Law wrote: On 3/21/24 11:19 AM, Vineet Gupta wrote: So if we go back to Robin's observation that scheduling dramatically increases the instruction count, perhaps we try a run with -fno-schedule-insns -fno

[committed] Fix RISC-V missing stack tie

wild. Been there, done that. Regression tested on rv64gc. Verified the scheduler no longer mucked up realpath by hand. Pushing to the trunk. Jeff commit c65046ff2ef0a9a46e59bc0b3369b2d226f6a239 Author: Jeff Law Date: Thu Mar 21 20:41:59 2024 -0600 [committed] Fix RISC-V missing stack tie

[gcc r14-9606] [committed] Fix RISC-V missing stack tie

https://gcc.gnu.org/g:c65046ff2ef0a9a46e59bc0b3369b2d226f6a239 commit r14-9606-gc65046ff2ef0a9a46e59bc0b3369b2d226f6a239 Author: Jeff Law Date: Thu Mar 21 20:41:59 2024 -0600 [committed] Fix RISC-V missing stack tie As some of you know, Raphael has been working on stack-clash

Re: scheduler queue flush (was Re: [gcc-15 0/3] RISC-V improve stack/array access by constant mat tweak)

On 3/21/24 11:19 AM, Vineet Gupta wrote: So if we go back to Robin's observation that scheduling dramatically increases the instruction count, perhaps we try a run with -fno-schedule-insns -fno-schedule-insns2 and see how the instruction counts compare. Oh yeah ! Robin hinted to this in

Re: scheduler queue flush (was Re: [gcc-15 0/3] RISC-V improve stack/array access by constant mat tweak)

On 3/21/24 8:36 AM, Vineet Gupta wrote: On 3/18/24 21:41, Jeff Law wrote: On 3/16/24 11:35 AM, Vineet Gupta wrote: Hi, This set of patches (for gcc-15) help improve stack/array accesses by improving constant materialization. Details are in respective patches. The first patch

Re: [gcc-15 2/3] RISC-V: avoid LUI based const mat: keep stack offsets aligned

On 3/19/24 2:05 PM, Vineet Gupta wrote: Just to be clear, the changes don't misalign the stack pointer at all. They merely have the potential to create *another* pointer into the stack which may or may not be aligned. Which is totally normal, it's no different than taking the address of a

Re: RISC-V: Use convert instructions instead of calling library functions

On 3/19/24 10:23 AM, Palmer Dabbelt wrote: On Mon, 18 Mar 2024 20:50:14 PDT (-0700), jeffreya...@gmail.com wrote: On 3/18/24 3:09 AM, Jivan Hakobyan wrote: As RV has round instructions it is reasonable to use them instead of calling the library functions. With my patch for the following

Re: [committed] m32r: Fix up m32r_setup_incoming_varargs [PR114175]

On 3/20/24 11:29 AM, Jakub Jelinek wrote: On Wed, Mar 20, 2024 at 10:58:05AM -0600, Jeff Law wrote: On 3/20/24 10:06 AM, Jakub Jelinek wrote: Like for x86-64, alpha or rs6000, m32r seems to be affected too. Just visually checked differences in c23-stdarg-9.c assembly in a cross without

Re: [committed] csky: Fix up csky_setup_incoming_varargs [PR114175]

On 3/20/24 10:04 AM, Jakub Jelinek wrote: Hi! Like for x86-64, alpha or rs6000, csky seems to be affected too. Just visually checked differences in c23-stdarg-9.c assembly in a cross without/with the patch, committed to trunk. 2024-03-20 Jakub Jelinek PR target/114175 *

Re: [committed] visium: Fix up visium_setup_incoming_varargs [PR114175]

On 3/20/24 10:08 AM, Jakub Jelinek wrote: Hi! Like for x86-64, alpha or rs6000, visium seems to be affected too. Just visually checked differences in c23-stdarg-9.c assembly in a cross without/with the patch, committed to trunk. 2024-03-20 Jakub Jelinek PR target/114175

Re: [committed] nds32: Fix up nds32_setup_incoming_varargs [PR114175]

On 3/20/24 10:06 AM, Jakub Jelinek wrote: Hi! Like for x86-64, alpha or rs6000, nds32 seems to be affected too. Just visually checked differences in c23-stdarg-9.c assembly in a cross without/with the patch, committed to trunk. 2024-03-20 Jakub Jelinek PR target/114175

Re: [committed] ft32: Fix up ft32_setup_incoming_varargs [PR114175]

On 3/20/24 10:05 AM, Jakub Jelinek wrote: Hi! Like for x86-64, alpha or rs6000, ft32 seems to be affected too. Just visually checked differences in c23-stdarg-9.c assembly in a cross without/with the patch, committed to trunk. 2024-03-20 Jakub Jelinek PR target/114175 *

Re: [committed] epiphany: Fix up epiphany_setup_incoming_varargs [PR114175]

On 3/20/24 10:05 AM, Jakub Jelinek wrote: Hi! Like for x86-64, alpha or rs6000, epiphany seems to be affected too. Just visually checked differences in c23-stdarg-9.c assembly in a cross without/with the patch, committed to trunk. 2024-03-20 Jakub Jelinek PR target/114175

Re: [committed] m32r: Fix up m32r_setup_incoming_varargs [PR114175]

On 3/20/24 10:06 AM, Jakub Jelinek wrote: Hi! Like for x86-64, alpha or rs6000, m32r seems to be affected too. Just visually checked differences in c23-stdarg-9.c assembly in a cross without/with the patch, committed to trunk. That fixed c23-stdarg-{6,8,9} execution tests. jeff

Re: [gcc-15 2/3] RISC-V: avoid LUI based const mat: keep stack offsets aligned

On 3/19/24 12:48 AM, Andrew Waterman wrote: On Mon, Mar 18, 2024 at 5:28 PM Vineet Gupta wrote: On 3/16/24 13:21, Jeff Law wrote: | 59944:add s0,sp,2047 < | 59948:mv a2,a0 | 5994c:mv a3,a1 | 59950:mv a0,sp | 59954:li a

Re: [gcc-15 0/3] RISC-V improve stack/array access by constant mat tweak

On 3/16/24 11:35 AM, Vineet Gupta wrote: Hi, This set of patches (for gcc-15) help improve stack/array accesses by improving constant materialization. Details are in respective patches. The first patch is the main change which improves SPEC cactu by 10%. Just to confirm. Yup, 10% reduction

Re: [PATCH, RFC] combine: Don't truncate const operand of AND if it's no benefits

On 3/10/24 11:41 PM, HAO CHEN GUI wrote: Hi, This patch tries to fix the problem when a canonical form doesn't benefit on a specific target. The const operand of AND is and with the nonzero bits of another operand in combine pass. It's a canonical form, but it's no benefits for the target

Re: [PATCH] RISC-V: Allow LICM hoist POLY_INT configuration code sequence

On 2/6/24 6:14 AM, Robin Dapp wrote: The root cause is this following RTL pattern, after fwprop1: (insn 82 78 84 9 (set (reg:DI 230)         (sign_extend:DI (minus:SI (subreg/s/v:SI (reg:DI 150 [ niters.10 ]) 0)                 (subreg:SI (reg:DI 221) 0 13 {subsi3_extended}      

Re: RISC-V: Use convert instructions instead of calling library functions

On 3/18/24 3:09 AM, Jivan Hakobyan wrote: As RV has round instructions it is reasonable to use them instead of calling the library functions. With my patch for the following C code: double foo(double a) {     return ceil(a); } GCC generates the following ASM code (before it was tail call)

Re: [PATCH v3] testsuite: Add a test case for negating FP vectors containing zeros

On 3/5/24 4:40 AM, Xi Ruoyao wrote: Recently I've fixed two wrong FP vector negate implementation which caused wrong sign bits in zeros in targets (r14-8786 and r14-8801). To prevent a similar issue from happening again, add a test case. Tested on x86_64 (with SSE2, AVX, AVX2, and AVX512F),

Re: [PATCH v5 1/1] RISC-V: Add support for XCVbi extension in CV32E40P

On 1/22/24 6:30 AM, Mary Bennett wrote: On 09/01/2024 18:43, Jeff Law wrote: On 1/8/24 06:14, Mary Bennett wrote: Spec: github.com/openhwgroup/core-v-sw/blob/master/specifications/ corev-builtin-spec.md Contributors:    Mary Bennett    Nandni Jamnadas    Pietra Ferreira    Charlie

[gcc r14-9532] [PATCH v5 1/1] RISC-V: Add support for XCVbi extension in CV32E40P

https://gcc.gnu.org/g:9eeca7753670d7bccd82e6ed7e4fe97cabd9a362 commit r14-9532-g9eeca7753670d7bccd82e6ed7e4fe97cabd9a362 Author: Mary Bennett Date: Mon Mar 18 21:32:56 2024 -0600 [PATCH v5 1/1] RISC-V: Add support for XCVbi extension in CV32E40P Spec:

Re: [PATCH V2] RISC-V: Update test expectancies with recent scheduler change

On 3/12/24 3:56 PM, Edwin Lu wrote: Given the recent change with adding the scheduler pipeline descriptions, many scan-dump failures emerged. Relax the expected assembler output conditions on the affected tests to reduce noise. gcc/testsuite/ChangeLog: *

Re: [PATCH] RISC-V: Fix C23 (...) functions returning large aggregates [PR114175]

On 3/18/24 12:54 PM, Edwin Lu wrote: We assume that TYPE_NO_NAMED_ARGS_STDARG_P don't have any named arguments and there is nothing to advance, but that is not the case for (...) functions returning by hidden reference which have one such artificial argument. This causes

Re: [PATCH] alpha: Fix alpha_setup_incoming_varargs [PR114175]

On 3/18/24 12:40 PM, Jakub Jelinek wrote: Hi! Like in the r14-9503 change on x86-64, I think Alpha also needs to function_arg_advance after the hidden return pointer argument if any. At least, the following patch changes the assembly of s1-s6 functions on the

[gcc r14-9531] [PATCH] RISC-V: Add XiangShan Nanhu microarchitecture.

https://gcc.gnu.org/g:d91a0cee3611f477730a1fc10beff050dfc800ec commit r14-9531-gd91a0cee3611f477730a1fc10beff050dfc800ec Author: Chen Jiawei Date: Mon Mar 18 20:54:45 2024 -0600 [PATCH] RISC-V: Add XiangShan Nanhu microarchitecture. This patch add XiangShan Nanhu cpu

Re: [PATCH] RISC-V: Add XiangShan Nanhu microarchitecture.

On 2/27/24 1:52 AM, Jiawei wrote: From: Chen Jiawei Co-Authored by: Lin Jiawei This patch add XiangShan Nanhu cpu microarchitecture, Nanhu is a 6-issue, superscalar, out-of-order processor. More details see: https://xiangshan-doc.readthedocs.io/zh-cn/latest/arch gcc/ChangeLog:

Re: [PATCH 02/11] riscv: xtheadmempair: Fix CFA reg notes

On 3/17/24 2:22 PM, Christoph Müllner wrote: On Fri, Apr 28, 2023 at 8:12 AM Christoph Muellner wrote: From: Christoph Müllner The current implementation triggers an assertion in dwarf2out_frame_debug_cfa_offset() under certain circumstances. The standard code uses REG_FRAME_RELATED_EXPR

Re: [gcc-15 1/3] RISC-V: avoid LUI based const materialization ... [part of PR/106265]

On 3/16/24 11:35 AM, Vineet Gupta wrote: ... if the constant can be represented as sum of two S12 values. The two S12 values could instead be fused with subsequent ADD insn. The helps - avoid an additional LUI insn - side benefits of not clobbering a reg e.g.

Re: [gcc-15 3/3] RISC-V: avoid LUI based const mat in prologue/epilogue expansion [PR/105733]

On 3/16/24 11:35 AM, Vineet Gupta wrote: If the constant used for stack offset can be expressed as sum of two S12 values, the constant need not be materialized (in a reg) and instead the two S12 bits can be added to instructions involved with frame pointer. This avoids burning a register and

Re: [gcc-15 2/3] RISC-V: avoid LUI based const mat: keep stack offsets aligned

On 3/16/24 11:35 AM, Vineet Gupta wrote: Noticed that new sum of two s12 splitter was generating following: | 059930 : | 59930: add sp,sp,-16 | 59934: lui t0,0xf | 59938: sd s0,0(sp) | 5993c: sd ra,8(sp) | 59940: add sp,sp,t0 |

Re: [PATCH V12]: Improve code sinking pass

On 3/13/24 4:22 AM, Richard Biener wrote: ... this hunk is OK (please test and split it out separatley). In the spirit of moving the stmt the least amount (in this case not schedule it within the basic-block). In the same spirit one would choose an earlier basic-block but only if the old

Re: [RFC] [PR tree-optimization/92539] Optimize away tests against invalid pointers

On 3/11/24 1:46 AM, Richard Biener wrote: On Sun, Mar 10, 2024 at 10:09 PM Jeff Law wrote: On 3/10/24 3:05 PM, Andrew Pinski wrote: On Sun, Mar 10, 2024 at 2:04 PM Jeff Law wrote: Here's a potential approach to fixing PR92539, a P2 -Warray-bounds false positive triggered by loop

Re: [PATCH] Fix PR ipa/113996

On 3/11/24 4:38 PM, Eric Botcazou wrote: Hi, this is a regression present on all active branches: the attached Ada testcase triggers an assertion failure when compiled with -O2 -gnatp -flto: /* Initialize the static chain. */ p = DECL_STRUCT_FUNCTION (fn)->static_chain_decl;

Re: [RFC] [PR tree-optimization/92539] Optimize away tests against invalid pointers

On 3/10/24 3:05 PM, Andrew Pinski wrote: On Sun, Mar 10, 2024 at 2:04 PM Jeff Law wrote: Here's a potential approach to fixing PR92539, a P2 -Warray-bounds false positive triggered by loop unrolling. As I speculated a couple years ago, we could eliminate the comparisons against bogus

[RFC] [PR tree-optimization/92539] Optimize away tests against invalid pointers

Here's a potential approach to fixing PR92539, a P2 -Warray-bounds false positive triggered by loop unrolling. As I speculated a couple years ago, we could eliminate the comparisons against bogus pointers. Consider: [local count: 30530247]: if (last_12 != [(void *)"aa" + 3B])

[committed] [PR tree-optimization/110199] Simplify MIN/MAX more often

So as I mentioned in the BZ, the case of t = MIN_EXPR (A, B) where we know something about the relationship between A and B can be trivially handled by some existing code in DOM. That existing code would simplify when A == B. But by testing GE and LE instead of EQ we can cover more cases

[gcc r14-9419] [committed] [PR tree-optimization/110199] Simplify MIN/MAX more often

https://gcc.gnu.org/g:8fe27ed193d60f6cd8b34761858a720c95eabbdb commit r14-9419-g8fe27ed193d60f6cd8b34761858a720c95eabbdb Author: jlaw Date: Sun Mar 10 11:58:00 2024 -0600 [committed] [PR tree-optimization/110199] Simplify MIN/MAX more often So as I mentioned in the BZ, the case

Reverting recent adjustment to expected output of sh port tests

With Jakub's twiddle to the forward propagation pass, the assembly code for pr59533-1.c has returned to its previous state. Thus I've reverted my patch which adjusted the expected output. Jeffcommit 6f7d000fcacef31a6947f95021e445c846170f92 Author: jlaw Date: Sat Mar 9 21:33:47 2024 -0700

[gcc r14-9417] Revert "[committed] Adjust expectations for pr59533-1.c"

https://gcc.gnu.org/g:6f7d000fcacef31a6947f95021e445c846170f92 commit r14-9417-g6f7d000fcacef31a6947f95021e445c846170f92 Author: jlaw Date: Sat Mar 9 21:33:47 2024 -0700 Revert "[committed] Adjust expectations for pr59533-1.c" This reverts commit

[committed] [target/102250] Document python requirement for risc-v

Not sure why nobody's taken care of this yet. Under certain circumstances python may be needed if you're building a RISC-V compiler. Here's what I've checked in. Happy to adjust if folks want to wordsmith it further. Jeffcommit 7c8f0a79a7e1e42f846ddbca14b98b47ddcfd178 Author: jlaw Date:

[gcc r14-9416] [committed] [target/102250] Document python requirement for risc-v

https://gcc.gnu.org/g:7c8f0a79a7e1e42f846ddbca14b98b47ddcfd178 commit r14-9416-g7c8f0a79a7e1e42f846ddbca14b98b47ddcfd178 Author: jlaw Date: Sat Mar 9 20:11:39 2024 -0700 [committed] [target/102250] Document python requirement for risc-v PR target/102250 gcc/

[committed] [PR target/111362] Fix compare-debug issue with mode switching

The issue here is the code we emit for mode-switching can change when -g is added to the command line. This is caused by processing debug notes occurring after a call which is the last real statement in a basic block. Without -g the CALL_INSN is literally the last insn in the block and the

[gcc r14-9415] [committed] [PR target/111362] Fix compare-debug issue with mode switching

https://gcc.gnu.org/g:50531b6d400945793a1d549e6ee941d989319d42 commit r14-9415-g50531b6d400945793a1d549e6ee941d989319d42 Author: jlaw Date: Sat Mar 9 19:27:32 2024 -0700 [committed] [PR target/111362] Fix compare-debug issue with mode switching The issue here is the code we emit

Re: [PATCH v2] contrib: Improve dg-extract-results.sh's Python detection

On 3/7/24 07:27, Sam James wrote: 'python' on some systems (e.g. SLES 15) might be Python 2. Prefer python3, then python, then python2 (as the script still tries to work there). contrib/ChangeLog: * dg-extract-results.sh: Check for python3 before python. Check for python2 last. OK.

[PR target/113001] Fix incorrect operand swapping in conditional move

actually has distinct patterns for those two cases. So swapping the operands is neither needed nor advisable. Regression tested on rv64gc and verified the new tests pass. Pushing to the trunk. jeff commit 10cbfcd60f9e5bdbe486e1c0192e0f168d899b77 Author: Jeff Law Date: Wed Mar 6 09:50:44

[gcc r14-9341] [PR target/113001] Fix incorrect operand swapping in conditional move

https://gcc.gnu.org/g:10cbfcd60f9e5bdbe486e1c0192e0f168d899b77 commit r14-9341-g10cbfcd60f9e5bdbe486e1c0192e0f168d899b77 Author: Jeff Law Date: Wed Mar 6 09:50:44 2024 -0700 [PR target/113001] Fix incorrect operand swapping in conditional move This bug totally fell off my radar

Re: [PATCH] middle-end/113576 - avoid out-of-bound vector element access

On 2/6/24 04:37, Richard Biener wrote: The following avoids accessing out-of-bound vector elements when native encoding a boolean vector with sub-BITS_PER_UNIT precision elements. The error was basing the number of elements to extract on the rounded up total byte size involved and the patch

Re: [PATCH] combine: Fix recent WORD_REGISTER_OPERATIONS check [PR113010]

On 3/4/24 09:49, Jakub Jelinek wrote: On Mon, Mar 04, 2024 at 05:18:39PM +0100, Rainer Orth wrote: On 2/26/24 17:17, Greg McGary wrote: The sign-bit-copies of a sign-extending load cannot be known until runtime on WORD_REGISTER_OPERATIONS targets, except in the case of a zero-extending MEM

Re: [PATCH] fwprop: Avoid volatile defines to be propagated

On 3/4/24 02:12, HAO CHEN GUI wrote: Hi Jeff, 在 2024/3/4 11:37, Jeff Law 写道: Can the same thing happen with a volatile memory load?  I don't think that will  be caught by the volatile_insn_p check. Yes, I think so. If the define rtx contains volatile memory references, it may hit the same

Fix 201001011-1.c on H8

Excerpt from gcc.sum: [...] PASS: gcc.c-torture/execute/20101011-1.c -O0 (test for excess errors) FAIL: gcc.c-torture/execute/20101011-1.c -O0 execution test PASS: gcc.c-torture/execute/20101011-1.c -O1 (test for excess errors) FAIL: gcc.c-torture/execute/20101011-1.c -O1 execution

Re: [PATCH] fwprop: Avoid volatile defines to be propagated

On 3/3/24 19:56, HAO CHEN GUI wrote: Hi Jeff, Thanks for your comments. 在 2024/3/4 6:02, Jeff Law 写道: Why specifically are you worried here?  Propagation of a volatile shouldn't in and of itself cause a problem.  We're not changing the number of volatile accesses or anything like

Re: [PATCH] rtl-optimization/113597 - recover base term for argument pointers

On 2/9/24 03:26, Richard Biener wrote: The following allows a base term to be derived from an existing MEM_EXPR, notably the points-to set of a MEM_REF base. For the testcase in the PR this helps RTL DSE elide stores to a stack temporary. This covers pointers to NONLOCAL which can be mapped

Re: [PATCH v2] DSE: Bugfix ICE after allow vector type in get_stored_val

On 2/29/24 06:28, Robin Dapp wrote: On 2/29/24 02:38, Li, Pan2 wrote: So it's going to check if V2SF can be tied to DI and V4QI with SI. I suspect those are going to fail for RISC-V as those aren't tieable. Yes, you are right. Different REG_CLASS are not allowed to be tieable in RISC-V.

Re: [PATCH] fwprop: Avoid volatile defines to be propagated

On 2/25/24 20:30, HAO CHEN GUI wrote: Hi, This patch tries to fix a potential problem which is raised by the patch for PR111267. The volatile asm operand tries to be propagated to a single set insn with the patch for PR111267. It has potential risk as the behavior is wrong. Currently

Re: [PATCH v2] testsuite: Make pr104992.c irrelated to target vector feature [PR113418]

On 2/29/24 00:06, Xi Ruoyao wrote: The vect_int_mod target selector is evaluated with the options in DEFAULT_VECTCFLAGS in effect, but these options are not automatically passed to tests out of the vect directories. So this test fails on targets where integer vector modulo operation is

Re: [committed] alpha: Introduce UMUL_HIGHPART rtx_code [PR113720]

On 3/3/24 12:43, Uros Bizjak wrote: umuldi3_highpart expander does: if (REG_P (operands[2])) operands[2] = gen_rtx_ZERO_EXTEND (TImode, operands[2]); on register_operand predicate, which also allows SUBREG RTX. So, subregs were emitted without ZERO_EXTEND RTX. But nowadays we

Re: [PATCH] middle-end/114070 - VEC_COND_EXPR folding

On 2/29/24 01:35, Richard Biener wrote: The following amends the PR114070 fix to optimistically allow the folding when we cannot expand the current vec_cond using vcond_mask and we're still before vector lowering. This leaves a small window between vectorization and lowering where we could

[14 regression] Fix insn types in risc-v port

So one of the broad goals we've had over the last few months has been to ensure that every insn has a scheduling type and that every insn is associated with an insn reservation in the scheduler. This avoids some amazingly bad behavior in the scheduler. I won't go through the gory details.

Re: [PATCH] combine: Don't simplify paradoxical SUBREG on WORD_REGISTER_OPERATIONS [PR113010]

On 2/26/24 17:17, Greg McGary wrote: The sign-bit-copies of a sign-extending load cannot be known until runtime on WORD_REGISTER_OPERATIONS targets, except in the case of a zero-extending MEM load. See the fix for PR112758. 2024-02-22 Greg McGary PR rtl-optimization/113010

<    3   4   5   6   7   8   9   10   11   12   >