Re: [Committed] RISC-V: Suppress warning

On 1/19/24 17:27, Juzhe-Zhong wrote: ../../gcc/config/riscv/riscv.cc: In function 'void riscv_init_cumulative_args(CUMULATIVE_ARGS*, tree, rtx, tree, int)': ../../gcc/config/riscv/riscv.cc:4879:34: error: unused parameter 'fndecl' [-Werror=unused-parameter] 4879 |

Re: [PATCH] Avoid ICE on m68k -fzero-call-used-regs -fpic [PR110934]

On 1/17/24 10:03, Mikael Pettersson wrote: PR110934 is a problem on m68k where -fzero-call-used-regs -fpic ICEs when clearing an FP register. The generic code generates an XFmode move of zero to that register, which becomes an XFmode load from initialized data, which due to -fpic uses a

Re: [PATCH] Avoid ICE in single-bit logical RMWs on m68k-uclinux [PR108640]

On 1/18/24 09:39, Mikael Pettersson wrote: When generating RMW logical operations on m68k, the backend recognizes single-bit operations and rewrites them as bit instructions on operands adjusted to address the intended byte. When offsetting the addresses the backend keeps the modes as SImode,

Re: [PATCH v5] RISC-V: Support XTheadVector extension

On 1/18/24 07:43, Christoph Müllner wrote: On Fri, Jan 12, 2024 at 4:18 AM Jun Sha (Joshua) wrote: This patch series presents gcc implementation of the XTheadVector extension [1]. [1] https://github.com/T-head-Semi/thead-extension-spec/ For some vector patterns that cannot be avoided, we

Re: [PATCH] RISC-V: Add split pattern to generate SFB instructions. [PR113095]

On 1/19/24 00:09, Kito Cheng wrote: Thanks! generally LGTM, but I would wait one more week to see any other comments :)Just a note. 113095 isn't marked as a regression, but it most definitely is a regression. So this meets the stage4 criteria. On Fri, Jan 19, 2024 at 3:05 PM Monk

Re: [middle-end PATCH] Prefer PLUS over IOR in RTL expansion of multi-word shifts/rotates.

On 1/19/24 09:05, Georg-Johann Lay wrote: Am 18.01.24 um 20:54 schrieb Roger Sayle: This patch tweaks RTL expansion of multi-word shifts and rotates to use PLUS rather than IOR for disjunctive operations.  During expansion of these operations, the middle-end creates RTL like (X<>C2) where

Re: [PATCH] combine: Don't optimize SIGN_EXTEND of MEM on WORD_REGISTER_OPERATIONS targets [PR113010]

On 1/17/24 20:53, Greg McGary wrote: On Tue, Jan 16, 2024 at 11:44 PM Richard Biener mailto:richard.guent...@gmail.com>> wrote: > On Tue, Jan 16, 2024 at 11:20 PM Greg McGary > wrote: > > > > The sign bit of a sign-extending load cannot be known until

Re: [PATCH 1/4] rtl-ssa: Run finalize_new_accesses forwards [PR113070]

On 1/13/24 08:43, Alex Coplan wrote: The next patch in this series exposes an interface for creating new uses in RTL-SSA. The intent is that new user-created uses can consume new user-created defs in the same change group. This is so that we can correctly update uses of memory when

Re: [PATCH] match: Do not select to branchless expression when target has movcc pattern [PR113095]

On 1/17/24 05:14, Richard Biener wrote: On Wed, 17 Jan 2024, Monk Chiang wrote: This allows the backend to generate movcc instructions, if target machine has movcc pattern. branchless-cond.c needs to be updated since some target machines have conditional move instructions, and the

Re: [PATCH, expand] Add const0 move checking for CLEAR_BY_PIECES optabs

On 1/15/24 19:04, HAO CHEN GUI wrote: Hi, This patch adds const0 move checking for CLEAR_BY_PIECES. The original vec_duplicate handles duplicates of non-constant inputs. But 0 is a constant. So even a platform doesn't support vec_duplicate, it could still do clear by pieces if it supports

Re: [PATCH] Mark ASM_OUTPUT_FUNCTION_LABEL ()'s DECL argument as used

On 1/15/24 02:22, Ilya Leoshkevich wrote: Compile tested for the ia64-elf target; bootstrap and regtest running on x86_64-redhat-linux. Ok for trunk when successful? ia64-elf build fails with the following warning: [all 2024-01-12 16:32:34]

Re: [RFA] [V3] new pass for sign/zero extension elimination

On 1/3/24 05:07, Richard Sandiford wrote: Jeff Law writes: I know we're deep into stage3 and about to transition to stage4. So if the consensus is for this to wait, I'll understand This it the V3 of the ext-dce patch based on Joern's work from last year. Changes since V2: Handle

Re: [PATCH v3 1/8] sched-deps.cc (find_modifiable_mems): Avoid exponential behavior

On 1/15/24 05:56, Maxim Kuvyrkov wrote: Hi Vladimir, Hi Jeff, Richard and Alexander have reviewed this patch and [I assume] have no further comments.  OK to merge? I think the question is whether or not we're too late. I know that Richard S has held off on his late-combine pass and I'm

Re: [PATCH 0/5] RISC-V: Relax the -march string for accept any order

On 1/9/24 17:58, Kito Cheng wrote: Oops, I should leave more context here: Actually we discussed that years ago, and most people agree with that, but I guess we are just missing that, and also the ISA string isn't so terribly long yet at that moment, however...the number of extensions are

Re: [PATCH 2/2] RISC-V/testsuite: Also verify if-conversion runs for pr105314.c

On 1/12/24 06:59, Maciej W. Rozycki wrote: On Fri, 12 Jan 2024, Andrew Pinski wrote: Verify that if-conversion succeeded through noce_try_store_flag_mask, as per PR rtl-optimization/105314, tightening the test case and making it explicit. gcc/testsuite/ *

Re: [PATCH] testsuite: Reduce gcc.dg/torture/inline-mem-cpy-1.c by 11 for simulators

On 1/2/24 14:07, Hans-Peter Nilsson wrote: On Tue, 2 Jan 2024, Jeff Law wrote: On 1/1/24 20:22, Hans-Peter Nilsson wrote: Tested mmix-knuth-mmixware (where all torture-variants of gcc.dg/torture/inline-mem-cpy-1.c now pass) and native x86_64-pc-linux-gnu. Also stepped through the test

Re: [patch, avr, ping #3] PR target/112944: Support .rodata in RAM for AVR64* and AVR128* devices

On 1/14/24 06:05, Georg-Johann Lay wrote: Ping #3 RFA: https://gcc.gnu.org/pipermail/gcc-patches/2023-December/640140.html Ping #1 https://gcc.gnu.org/pipermail/gcc-patches/2023-December/640981.html Ping #2 https://gcc.gnu.org/pipermail/gcc-patches/2024-January/641912.html This is a patch

[committed] Fix MIPS bootstrap

regression test data. Pushed to the trunk, Jeff commit e927cfa842c16bea902500e69ab4eca2ef15af4e Author: Jeff Law Date: Sun Jan 14 07:53:49 2024 -0700 [committed] Fix MIPS bootstrap mips bootstraps have been broken for a while. They've been triggering an error about mutually exclusiv

Re: [PATCH] config: delete unused CYG_AC_PATH_LIBERTY macro

On 1/9/24 19:04, Mike Frysinger wrote: Nothing uses this, so delete it to avoid confusion. config/ChangeLog: * acinclude.m4 (CYG_AC_PATH_LIBERTY): Delete. OK jeff

Re: [PATCH] Add a late-combine pass [PR106594]

On 1/10/24 06:01, Richard Sandiford wrote: So to get an idea for expectations: would it be a requirement that a GCC 15 submission is enabled unconditionally and all known issues in the ports fixed? I don't think we need to fix those latent port issues as a hard requirement. I try to

Re: [PATCH] Add a late-combine pass [PR106594]

On 1/10/24 06:35, Richard Biener wrote: I think x86 maintainers could opt to disable the pass - so it would be opt-out. It's reasonable to expect them to fix the backend given there's nothing really wrong with the new pass, it just does something that wasn't done before at that point?

Re: [PATCH] vect: Fix ICE in vect_analyze_loop_costing [PR113210]

On 1/6/24 01:59, Jakub Jelinek wrote: Hi! The following testcase ICEs (on ARM/RISCV with certain options), because niters analysis computes number of latch executions for the loop as (short unsigned int) (a.0_1 + 255) + 1 > 256 ? ~(short unsigned int) (a.0_1 + 255) : 0 where a.0_1 is

Re: [PATCH v2 2/2] asan: Align .LASANPC on function boundary

On 1/2/24 12:41, Ilya Leoshkevich wrote: GCC can emit code between the function label and the .LASANPC label, making the latter unaligned. Some architectures cannot load unaligned labels directly and require literal pool entries, which is inefficient. Move the invocation of

Re: [PATCH v3] EXPR: Emit an truncate if 31+ bits polluted for SImode

On 1/3/24 16:39, Richard Sandiford wrote: YunQiang Su writes: On TRULY_NOOP_TRUNCATION_MODES_P (DImode, SImode)) == true platforms, if 31 or above bits is polluted by an bitops, we will need an truncate. Let's emit one, and mark let's use the same hardreg as in and out, the RTL may like:

Re: [PATCH] Keep track of the FUNCTION_BEG note

On 1/5/24 09:28, Richard Sandiford wrote: function.cc emits a NOTE_FUNCTION_BEG after all arguments have been copied to pseudos. It then records this note in parm_birth_insn. Various other pieces of code use this insn as a convenient place to insert things at the start of the function.

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

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 Keaney Jessica Mills Craig Blackmore Simon Cook Jeremy Bennett

Re: [PATCH 0/5] RISC-V: Relax the -march string for accept any order

On 1/8/24 06:47, Kito Cheng wrote: Do you know how to build a ISA string with following extension? - g - c - zba - zbs - svnapot - zve64d - zvl128b Don't trial and error with your gcc and don't read RISC-V ISA spec! OK, I believe it's impossible for most people, even I work for RISC-V so

Re: [PATCH] c-family: copy attribute diagnostic fixes [PR113262]

On 1/9/24 01:52, Jakub Jelinek wrote: Hi! The copy attributes is allowed on decls as well as types and even has checks whether decl (set to *node) is DECL_P or TYPE_P, but for diagnostics unconditionally uses DECL_SOURCE_LOCATION (decl), which obviously only works if it applies to a decl.

Re: [PATCH v2] RISC-V: T-HEAD: Add support for the XTheadInt ISA extension

On 11/17/23 00:33, Jin Ma wrote: The XTheadInt ISA extension provides acceleration interruption instructions as defined in T-Head-specific: * th.ipush * th.ipop Ref: https://github.com/T-head-Semi/thead-extension-spec/releases/download/2.3.0/xthead-2023-11-10-2.3.0.pdf gcc/ChangeLog:

Re: [PATCH v4] RISC-V: Adds the prefix "th." for the instructions of XTheadVector.

On 1/8/24 16:04, 钟居哲 wrote: This patch looks ok from myside. Likewise. So I think the only question for this specific patch is whether or not it makes sense to include it now or wait for more of the thead bits to get to acceptance. I tend to think it should wait since I don't think it

Re: [PATCH v3] RISC-V: Bugfix for doesn't honor no-signed-zeros option

On 1/8/24 03:45, Richard Biener wrote: On Tue, Jan 2, 2024 at 2:37 PM wrote: From: Pan Li According to the sematics of no-signed-zeros option, the backend like RISC-V should treat the minus zero -0.0f as plus zero 0.0f. Consider below example with option -fno-signed-zeros. void test

[committed] Adding missing prototype for __clzhi2 to xstormy port

xstormy16 has failed since the c99 transition due to a missing prototype for __clzhi2 in the implementation of storm16_count_loaading_zeros. This fixes the missing prototype. Pushed to the trunk. jeffcommit 9f7afa99c67f039e43019ebd08d14a7f01e2d89c Author: Jeff Law Date: Tue Jan 9 10:21:28

[committed] Fix minor bug in epiphany port

0beb20c01cf7120c724f9882be41a77e970fe63d Author: Jeff Law Date: Tue Jan 9 10:17:54 2024 -0700 [committed] Fix minor bug in epiphany port So I consider this port dead as it semi-randomly fails in reload due to unrelated changes earlier in the gimple and RTL pipelines. Regardless

[committed] Fix minor bug on mn103 port

Richard Sandiford debugged a failure on the mn103 port with his late-combine patches down to the subdi3 pattern not specifying the isa on alternatives which required newer variants of the chip family. This patch adds the missing isa attribute and the port now works with his late-combine

Re: [PATCH] RISC-V: Also handle sign extension in branch costing

On 1/7/24 17:06, Maciej W. Rozycki wrote: Complement commit c1e8cb3d9f94 ("RISC-V: Rework branch costing model for if-conversion") and also handle extraneous sign extend operations that are sometimes produced by `noce_try_cmove_arith' instead of zero extend operations, making branch costing

Re: [Committed] RISC-V: Use MAX instead of std::max [VSETVL PASS]

On 1/7/24 16:07, 钟居哲 wrote: Since in the previous review from Robin, he have ever asked me change std::max into MAX, I thought the policy is preferring MAX instead of std::max. I change the codes to make them consistent but it seems I am wrong. So is it reasonable that I change all

Re: [PATCH] Add a late-combine pass [PR106594]

On 1/8/24 12:11, Richard Sandiford wrote: Thanks. That led me to the following, which seems a bit more plausible than my first attempt. I'll test it on aarch64-linux-gnu and x86_64-linux-gnu. Does it look OK? It looks reasonable to me. I'm going to send another failure (ICE in

Re: [PATCH] Add a late-combine pass [PR106594]

On 1/8/24 09:59, Richard Sandiford wrote: This is a bit of a hopeful stab, but is the problem that recog_data still had the previous contents of insn 3674, and so extract_insn_cached wrongly thought that it doesn't need to do anything? If so, does something like: diff --git a/gcc/recog.cc

Re: [PATCH] match.pd: Convert {I, X}OR of two values ANDed with alien CSTs to PLUS [PR108477]

On 1/8/24 09:57, Andrew Pinski wrote: On Mon, Jan 8, 2024 at 6:44 AM Uros Bizjak wrote: Instead of converting XOR or PLUS of two values, ANDed with two constants that have no bits in common, to IOR expression, convert IOR or XOR of said two ANDed values to PLUS expression. I think this

Re: [PATCH] Add a late-combine pass [PR106594]

On 1/8/24 04:52, Richard Sandiford wrote: Jeff Law writes: The other issue that's been in the back of my mind is costing. But I think the model here is combine without regards to cost. No, it does take costing into account. For size, it's the usual "sum up the before and after

Re: [PATCH] Add a late-combine pass [PR106594]

On 1/5/24 10:35, Richard Sandiford wrote: Jeff Law writes: On 10/24/23 12:49, Richard Sandiford wrote: This patch adds a combine pass that runs late in the pipeline. There are two instances: one between combine and split1, and one after postreload. So have you done any investigation

Re: [RFA] [V3] new pass for sign/zero extension elimination

On 1/3/24 05:07, Richard Sandiford wrote: + + if (GET_CODE (x) == ZERO_EXTRACT) + { + /* If either the size or the start position is unknown, +then assume we know nothing about what is overwritten. +This is overly conservative,

Re: Stage 4 date

On 1/7/24 08:48, waffl3x via Gcc wrote: https://gcc.gnu.org/develop.html#timeline The date for stage 4 is listed as the 8th on here, is that date final? There is at least 1 patch pending (mine) that is complete but Jason Merril hasn't been active for a few days. He had expressed to me that he

Re: [Committed] RISC-V: Use MAX instead of std::max [VSETVL PASS]

On 1/6/24 17:36, Juzhe-Zhong wrote: Obvious fix, Committed. gcc/ChangeLog: * config/riscv/riscv-vsetvl.cc: replace std::max by MAX. Curious why you made this change -- in general we're moving to std::{min,max,swap} and away from macro-ized min/max/swap. Jeff

Re: [patch, testsuite, applied] PR52641 Fix more fallout from sloppy tests.

On 1/7/24 10:17, Georg-Johann Lay wrote: Am 07.01.24 um 17:45 schrieb Jeff Law: On 1/7/24 08:53, Georg-Johann Lay wrote: Made some tests more generic so they can pass on more targets. Johann -- testsuite/52641: Fix fallout from sloppy tests. gcc/testsuite/  PR testsuite/52641

[committed] Fix typo in last change

Tester started complaining about this change as soon as it went in. Clearly there's an extraneous "short" in the testcase. Pushed to the trunk. Jeff commit 66d82874d2254bcb0124f77e6be220d299eab5f1 Author: Jeff Law Date: Sun Jan 7 09:52:44 2024 -0700 Fix typo in l

Re: [patch, testsuite, applied] PR52641 Fix more fallout from sloppy tests.

On 1/7/24 08:53, Georg-Johann Lay wrote: Made some tests more generic so they can pass on more targets. Johann -- testsuite/52641: Fix fallout from sloppy tests. gcc/testsuite/ PR testsuite/52641 * gcc.dg/torture/pr110838.c: Use proper shift offset to get MSB or int. *

Re: [RFA] [V3] new pass for sign/zero extension elimination

On 1/4/24 13:44, Xi Ruoyao wrote: I have successfully bootstrapped and regtested the patch on loongarch64- linux-gnu. The test cases in the patch (intended for RISC-V) also works on LoongArch per my manual testing. I find myself wondering if we should create some kind of target-supports

Re: [committed] RISC-V: Add crypto vector builtin function.

On 1/4/24 20:24, Palmer Dabbelt wrote: On Thu, 04 Jan 2024 19:17:21 PST (-0800), juzhe.zh...@rivai.ai wrote: Hi, Wang Feng. Your patch has some ICEs: FAIL: gcc.target/riscv/rvv/base/zvbc-intrinsic.c (internal compiler error: RTL check: expected code 'const_int', have 'reg' in

Re: [PATCH] Improve __builtin_popcount* (x) == 1 generation if x is known != 0 [PR90693]

On 1/4/24 02:11, Jakub Jelinek wrote: Hi! We expand __builtin_popcount* (x) == 1 as x ^ (x - 1) > x - 1, either unconditionally in tree-ssa-math-opts.cc if we don't have a direct optab support for popcount, or during expansion where we compare the costs of comparison of the popcount against

Re: [PATCH] scev: Avoid ICE on results used in abnormal PHI args [PR113201]

On 1/4/24 02:34, Jakub Jelinek wrote: Hi! The following testcase ICEs when rslt is SSA_NAME_OCCURS_IN_ABNORMAL_PHI and we call replace_uses_by with a INTEGER_CST def, where it ICEs on: if (e->flags & EDGE_ABNORMAL && !SSA_NAME_OCCURS_IN_ABNORMAL_PHI (val))

Re: [PATCH] Avoid ICE with m68k-elf -malign-int and libcalls

On 1/4/24 02:23, Mikael Pettersson wrote: emit_library_call_value_1 calls emit_push_insn with NULL_TREE for TYPE. Sometimes emit_push_insn needs to assign a temp with that TYPE, which causes a segfault. Fixed by computing the TYPE from MODE when needed. Original patch by Thorsten Otto.

Re: [RFA] [V3] new pass for sign/zero extension elimination

On 1/4/24 06:36, Stefan Schulze Frielinghaus wrote: I have successfully bootstrapped and regtested the patch on s390. Out of curiosity I also ran some benchmarks which didn't show much changes except in one case which I will have to analyze further. If there is anything interesting I will

Re: [PATCH] Match: Improve inverted_equal_p for bool and `^` and `==` [PR113186]

On 12/31/23 21:03, Andrew Pinski wrote: For boolean types, `a ^ b` is a valid form for `a != b`. This means for gimple_bitwise_inverted_equal_p, we catch some inverted value forms. This patch extends inverted_equal_p to allow matching of `^` with the corresponding `==`. Note in the testcase

Re: [PATCH v2 1/2] Implement ASM_DECLARE_FUNCTION_NAME using ASM_OUTPUT_FUNCTION_LABEL

On 1/2/24 12:41, Ilya Leoshkevich wrote: gccint recommends using ASM_OUTPUT_FUNCTION_LABEL in ASM_DECLARE_FUNCTION_NAME, but many implementations use ASM_OUTPUT_LABEL instead. It's inconsistent and prevents changes to ASM_OUTPUT_FUNCTION_LABEL from affecting the respective targets. ---

Re: [PATCH RFA] opts: -Werror=foo always implies -Wfoo [PR106213]

On 12/19/23 15:17, Jason Merrill wrote: Tested x86_64-pc-linux-gnu, OK for trunk? -- 8< -- -Werror=foo implying -Wfoo wasn't working for -Wdeprecated-copy-dtor, because it is specified as the value 2 of warn_deprecated_copy, which shows up as CLVC_EQUAL, which is not one of the three

Re: [PATCH] Add a late-combine pass [PR106594]

On 10/24/23 12:49, Richard Sandiford wrote: This patch adds a combine pass that runs late in the pipeline. There are two instances: one between combine and split1, and one after postreload. So have you done any investigation on cases caught by your new pass between combine and split1 to

Re: [PATCH] RISC-V: Implement ZACAS extensions

On 1/2/24 13:17, trdth...@gmail.com wrote: From: trdthg This patch supports Zacas extension. It includes instruction's machine description and built-in functions. gcc/ChangeLog: * common/config/riscv/riscv-common.cc (riscv_implied_info): Add zacas extensions.

Re: [PATCH] testsuite: Reduce gcc.dg/torture/inline-mem-cpy-1.c by 11 for simulators

On 1/1/24 20:22, Hans-Peter Nilsson wrote: Tested mmix-knuth-mmixware (where all torture-variants of gcc.dg/torture/inline-mem-cpy-1.c now pass) and native x86_64-pc-linux-gnu. Also stepped through the test for native, w/wo. RUN_FRACTION defined to see that it worked as intended. You may

Re: [PATCH] RISC-V: RVV: add toggle to control vsetvl pass behavior

On 12/22/23 12:45, Vineet Gupta wrote: RVV requires VSET?VL? instructions to dynamically configure VLEN at runtime. There's a custom pass to do that which has a simple mode which generates a VSETVL for each V insn and a lazy/optimal mode which uses LCM dataflow to move VSETVL around,

Re: [PATCH] config-ml.in: Fix multi-os-dir search

On 1/1/24 09:48, YunQiang Su wrote: When building multilib libraries, CC/CXX etc are set with an option -B*/lib/, instead of -B/lib/. This will make some trouble in some case, for example building cross toolchain based on Debian's cross packages: If we have libc6-dev-i386-amd64-cross

Re: [PATCH] Improved RTL expansion of field assignments into promoted registers.

On 12/28/23 12:35, Roger Sayle wrote: Hi Jeff, Thanks for the speedy review. On 12/28/23 07:59, Roger Sayle wrote: This patch fixes PR rtl-optmization/104914 by tweaking/improving the way that fields are written into a pseudo register that needs to be kept sign extended. Well, I think

Re: [PATCH] Improved RTL expansion of field assignments into promoted registers.

On 12/30/23 21:34, YunQiang Su wrote: Right. But that's the whole point behind avoiding the narrowing subreg and forcing use of a truncate operation. So basically the question becomes is there a way to modify those bits in a way that GCC doesn't know that it needs to to truncate/extend?

Re: [committed] RISC-V: Modify copyright year of vector-crypto.md

On 1/1/24 19:25, Feng Wang wrote: gcc/ChangeLog: * config/riscv/vector-crypto.md: Modify copyright year. --- gcc/config/riscv/vector-crypto.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/gcc/config/riscv/vector-crypto.md b/gcc/config/riscv/vector-crypto.md

Re: [PATCH] libsanitizer: Enable LSan and TSan for riscv64

On 1/2/24 06:56, Andreas Schwab wrote: All new (tsan) tests are working as expected. * configure.tgt (riscv64-*-linux*): Enable LSan and TSan. OK Jeff

[RFA] [V3] new pass for sign/zero extension elimination

I know we're deep into stage3 and about to transition to stage4. So if the consensus is for this to wait, I'll understand This it the V3 of the ext-dce patch based on Joern's work from last year. Changes since V2: Handle MINUS Minor logic cleanup for SUBREGs in ext_dce_process_sets

Re: [PATCH] RISC-V: Count pointer type SSA into RVV regs liveness for dynamic LMUL cost model

On 12/28/23 18:21, Juzhe-Zhong wrote: This patch fixes the following choosing unexpected big LMUL which cause register spillings. Before this patch, choosing LMUL = 4: addisp,sp,-160 addiw t1,a2,-1 li a5,7 bleut1,a5,.L16 vsetivli

Re: [PATCH v4] RISC-V: Adds the prefix "th." for the instructions of XTheadVector.

On 12/28/23 21:19, Jun Sha (Joshua) wrote: This patch adds th. prefix to all XTheadVector instructions by implementing new assembly output functions. We only check the prefix is 'v', so that no extra attribute is needed. gcc/ChangeLog: * config/riscv/riscv-protos.h

Re: [PATCH] Pass GUILE down to subdirectories

On 12/30/23 14:21, Tom Tromey wrote: When I enable cgen rebuilding in the binutils-gdb tree, the default is to run cgen using 'guile'. However, on my host, guile is guile 2.2, which doesn't work for me -- I have to use guile3.0. This patch arranges to pass "GUILE" down to subdirectories, so

Re: [PATCH 1/2] RTX_COST: Count instructions

On 12/29/23 10:46, YunQiang Su wrote: When we try to combine RTLs, the result may be very complex, and `rtx_cost` may think that it need lots of costs. But in fact, it may match a pattern in machine descriptions, which may emit only 1 or 2 hardware instructions. This combination may be

Re: [PATCH] Improved RTL expansion of field assignments into promoted registers.

On 12/28/23 19:07, YunQiang Su wrote: In general, I agree with this change. When gcc12 on RV64, more than one `sext.w` will be produced with our test. (Note, use -O1). There are two things that help here. The first is that the most significant bit never appears in the middle of a field,

Re: [PATCH v2] RISC-V: XFAIL pr30957-1.c when loop vectorized with variable factor

On 12/28/23 22:56, Li, Pan2 wrote: Thanks Jeff. I think I locate where aarch64 performs the trick here. 1. In the .final we have rtl like (insn:TI 6 8 29 (set (reg:SF 32 v0) (const_double:SF -0.0 [-0x0.0p+0]))

Re: [PATCH v2] RISC-V: XFAIL pr30957-1.c when loop vectorized with variable factor

On 12/28/23 17:42, Li, Pan2 wrote: Thanks Jeff for comments, and Happy new year! Interesting. So I'd actually peel one more layer off this onion. Why do the aarch64 and riscv targets generate different constants (0.0 vs -0.0)? Yeah, it surprise me too when debugging the foo function.

Re: [PATCH v3] EXPR: Emit an truncate if 31+ bits polluted for SImode

On 12/24/23 05:24, Roger Sayle wrote: What's exceedingly weird is T_N_T_M_P (DImode, SImode) isn't actually a truncation! The output precision is first, the input precision is second. The docs explicitly state the output precision should be smaller than the input precision (which makes

Re: [PATCH] Improved RTL expansion of field assignments into promoted registers.

On 12/28/23 07:59, Roger Sayle wrote: This patch fixes PR rtl-optmization/104914 by tweaking/improving the way that fields are written into a pseudo register that needs to be kept sign extended. Well, I think "fixes" is a bit of a stretch. We're avoiding the issue by changing the early RTL

Re: [PATCH v3] EXPR: Emit an truncate if 31+ bits polluted for SImode

On 12/24/23 01:11, YunQiang Su wrote: Yes. I also guess so. Any new idea? Well, I see multiple intertwined issues and I think MIPS has largely mucked this up. At a high level DI -> SI truncation is not a nop on MIPS64. We must explicitly sign extend the value from SI->DI to preserve the

Re: [PATCH v2] RISC-V: XFAIL pr30957-1.c when loop vectorized with variable factor

On 12/26/23 02:34, pan2...@intel.com wrote: From: Pan Li This patch would like to XFAIL the test case pr30957-1.c for the RVV when build the elf with some configurations (list at the end of the log) It will be vectorized during vect_transform_loop with a variable factor. It won't benefit

Re: [PATCH V2] RISC-V: Disallow transformation into VLMAX AVL for cond_len_xxx when length is in range [0,31]

On 12/26/23 19:38, Juzhe-Zhong wrote: Notice we have this following situation: vsetivlizero,4,e32,m1,ta,ma vlseg4e32.v v4,(a5) vlseg4e32.v v12,(a3) vsetvli a5,zero,e32,m1,tu,ma ---> This is redundant since VLMAX AVL = 4 when it

Re: [ARC PATCH] Table-driven ashlsi implementation for better code/rtx_costs.

On 12/23/23 16:37, Roger Sayle wrote: One of the cool features of the H8 backend is its use of tables to select optimal shift implementations for different CPU variants. This patch borrows (plagiarizes) that idiom for SImode left shifts in the ARC backend (for CPUs without a

Re: [PATCH] RISC-V: Fix misaligned stack offset for interrupt function

On 12/25/23 01:45, Kito Cheng wrote: `interrupt` function will backup fcsr register, but it fixed to SImode, it's not big issue since fcsr only used 8 bits so far, however the offset should still using UNITS_PER_WORD to prevent the stack offset become non 8 byte aligned, it will cause problem

Re: [PATCH] RISC-V: Add crypto machine descriptions

On 12/26/23 19:47, Kito Cheng wrote: Thanks Feng, the patch is LGTM from my side, I am happy to accept vector crypto stuffs for GCC 14, it's mostly intrinsic stuff, and the only few non-intrinsic stuff also low risk enough (e.g. vrol, vctz) I won't object. I'm disappointed that we're in a

Re: 回复：[PATCH v3 2/6] RISC-V: Split csr_operand in predicates.md for vector patterns.

On 12/26/23 19:49, joshua wrote: Hi Jeff, Yes, I will change soemthing in vector_csr_operand in the following patches. Constraints will be added that the AVL cannot be encoded as an immediate for xtheadvecotr vsetvl. Ah. Thanks. Makes sense. jeff

Re: [PATCH v3] EXPR: Emit an truncate if 31+ bits polluted for SImode

On 12/23/23 17:49, Roger Sayle wrote: Hi YunQiang (and Jeff), MIPS claims TRULY_NOOP_TRUNCATION_MODES_P (DImode, SImode)) == true based on that the hard register is always sign-extended, but here the hard register is polluted by zero_extract. I suspect that the bug here is that the MIPS

Re: [PATCH v3] EXPR: Emit an truncate if 31+ bits polluted for SImode

On 12/23/23 15:46, YunQiang Su wrote: Jeff Law 于2023年12月24日周日 00:51写道： On 12/23/23 01:58, YunQiang Su wrote: On TRULY_NOOP_TRUNCATION_MODES_P (DImode, SImode)) == true platforms, if 31 or above bits is polluted by an bitops, we will need an truncate. Let's emit one, and mark let's use

Re: [PATCH v1] RISC-V: XFAIL pr30957-1.c when loop vectorized with variable factor

On 12/23/23 04:07, pan2...@intel.com wrote: From: Pan Li This patch would like to XFAIL the test case pr30957-1.c for the RVV when build the elf with some configurations (list at the end of the log) It will be vectorized during vect_transform_loop with a variable factor. It won't benefit

Re: [PATCH v3] EXPR: Emit an truncate if 31+ bits polluted for SImode

On 12/23/23 01:58, YunQiang Su wrote: On TRULY_NOOP_TRUNCATION_MODES_P (DImode, SImode)) == true platforms, if 31 or above bits is polluted by an bitops, we will need an truncate. Let's emit one, and mark let's use the same hardreg as in and out, the RTL may like: (insn 21 20 24 2 (set

Re: [PATCH v2] RISC-V: XFail the signbit-5 run test for RVV

On 12/23/23 05:39, pan2...@intel.com wrote: From: Pan Li This patch would like to XFail the signbit-5 run test case for the RVV. Given the case has one limitation like "This test does not work when the truth type does not match vector type." in the beginning of the test file. Aka, the RVV

Re: 回复：[PATCH v3 0/6] RISC-V: Support XTheadVector extension

On 12/22/23 01:07, juzhe.zh...@rivai.ai wrote: You mean theadvector doesn't want the current RVV1.0 register overlap magic  as follows ? * The destination EEW is smaller than the source EEW and the overlap is in the lowest-numbered part of the source register group (e.g.,

Re: [PATCH] RISC-V: Make PHI initial value occupy live V_REG in dynamic LMUL cost model analysis

On 12/22/23 02:51, Juzhe-Zhong wrote: Consider this following case: foo: ble a0,zero,.L11 lui a2,%hi(.LANCHOR0) addisp,sp,-128 addia2,a2,%lo(.LANCHOR0) mv a1,a0 vsetvli a6,zero,e32,m8,ta,ma vid.v v8

Re: [PATCH] RISC-V: Add --with-cmodel configure-time argument

On 12/21/23 12:35, Palmer Dabbelt wrote: On Thu, 21 Dec 2023 11:18:22 PST (-0800), jeffreya...@gmail.com wrote: On 12/20/23 11:41, Palmer Dabbelt wrote: I couldn't find another way to set the default code model. gcc/ChangeLog: * config.gcc (RISC-V): Add --with-cmodel *

Re: [PATCH] RISC-V: Add --with-cmodel configure-time argument

On 12/20/23 11:41, Palmer Dabbelt wrote: I couldn't find another way to set the default code model. gcc/ChangeLog: * config.gcc (RISC-V): Add --with-cmodel * config/riscv/riscv.h (TARGET_DEFAULT_CMODEL): Use TARGET_RISCV_DEFAULT_CMODEL OK once its sniff tested.

Re: [PATCH v1] RISC-V: XFail the signbit-5 run test for RVV

On 12/20/23 19:25, pan2...@intel.com wrote: From: Pan Li This patch would like to XFail the signbit-5 run test case for the RVV. Given the case has one limitation like "This test does not work when the truth type does not match vector type." in the beginning of the test file. Aka, the RVV

Re: [PATCH v5 2/3] RISC-V: Add crypto machine descriptions

On 12/20/23 20:50, juzhe.zh...@rivai.ai wrote: + (and:VI + (match_operand:VI 3 "register_operand" "vr, vr, vr, vr") + (not:VI (match_operand:VI 4 "register_operand" "vr, vr, vr, vr"))) This order should be swapped like ARM SVE: (define_expand "@cond_bic"  

Re: [PATCH 1/3][RFC] RISC-V: Add non-vector types to pipelines

On 12/20/23 15:11, Edwin Lu wrote:   (define_insn_reservation "generic_xfer" 3     (and (eq_attr "tune" "generic") -   (eq_attr "type" "mfc,mtc,fcvt,fmove,fcmp")) +   (eq_attr "type" "mfc,mtc,fcvt,fmove,fcmp,cbo"))     "alu") cbo is probably closer to a load/store than it is a

Re: [PATCH v3 4/6] RISC-V: Adds the prefix "th." for the instructions of XTheadVector.

On 12/20/23 15:48, 钟居哲 wrote: >> So rather than looking at the mode, would it make more sense to have an attribute (or re-use an existing attribute) to identify which opcodes are going to need prefixing?  We've got access to the INSN via current_output_insn.  So we can lookup attributes

Re: [External] Re: [PATCH] RISC-V: Fix RISCV_FUSE_ZEXTWS fusion condition

On 12/20/23 20:30, Wang Pengcheng wrote: Yeah, I just found it when I tried to understand the original fusion implementation commit. :-) Ah. If you have any questions, don't hesitate to reach out. While I didn't do the original implementation (that was Philipp T. and his team), the

Re: [PATCH v3 0/6] RISC-V: Support XTheadVector extension

On 12/20/23 20:30, juzhe.zh...@rivai.ai wrote: OK.  Sounds reasonable. But from my side, I used to commit patches after full coverage testing. Understood. And it's appreciated -- the code you're doing hits a wide variety of configurations, so the wider testing is probably applicable.

Re: [PATCH v3 0/6] RISC-V: Support XTheadVector extension

On 12/20/23 16:08, 钟居哲 wrote: Btw, rv32/rv64gc or rv32/rv64 gcv testing is not enough. We need full coverage testing, since we always commit patch after no regression testing on full coverage testing: No. It is unreasonable to require this large of test matrix for the vast majority if

Re: PING^1 [PATCH] sched: Remove debug counter sched_block

On 12/11/23 23:17, Kewen.Lin wrote: Hi, Gentle ping this: https://gcc.gnu.org/pipermail/gcc-patches/2023-November/636597.html BR, Kewen on 2023/11/15 17:01, Kewen.Lin wrote: Hi, on 2023/11/10 01:40, Alexander Monakov wrote: I agree with the concern. I hoped that solving the problem by

Re: [PATCH] sel-sched: Verify change before replacing dest in EXPR_INSN_RTX [PR112995]

On 12/15/23 01:52, Kewen.Lin wrote: Hi, PR112995 exposed one issue in current try_replace_dest_reg that the result rtx insn after replace_dest_with_reg_in_expr is probably unable to match any constraints. Although there are some checks on the changes onto dest or src of orig_insn, none is

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