Re: RISC-V sign extension query

On 9/18/23 13:45, Vineet Gupta wrote: For the cases which do require sign extends, but not being eliminated due to "missing definition(s)" I'm working on adapting Ajit's REE ABI interfaces work [2] to work for RISC-V as well. I wonder if we could walk the DECL_ARGUMENTS for

Re: RISC-V sign extension query

On 9/18/23 13:45, Vineet Gupta wrote: Hi Jeff, Andrew I've been looking into redundant sign extension and while there are things to be improved in REE, there's something I wanted to confirm before heading off into the weeds. Consider the test below: int foo(int unused, int n, unsigned

Re: [PATCH v1] RISC-V: Bugfix for scalar move with merged operand

On 9/18/23 04:00, Robin Dapp wrote: I must be missing something. Doesn't insn 10 broadcast the immediate 0x2 to both elements of r142?!? What am I missing? It is indeed a bit misleading. The difference is in the mask which is not displayed in the short form. So we actually use a vec_dup

Re: [PATCH] tree-optimization/111294 - backwards threader PHI costing

On 9/14/23 07:23, Richard Biener via Gcc-patches wrote: This revives an earlier patch since the problematic code applying extra costs to PHIs in copied blocks we couldn't make any sense of prevents a required threading in this case. Instead of coming up with an artificial other costing the

Re: [RFC PATCH 2/2] RISC-V: Update testsuite for type-changed builtins

On 9/6/23 20:17, Tsukasa OI wrote: From: Tsukasa OI This commit replaces the type of the builtin used in the testsuite. Even without this commit, it won't cause any test failures but changed so that no confusion occurs. gcc/testsuite/ChangeLog: * gcc.target/riscv/zbc32.c: Make

Re: [PATCH 1/2] RISC-V: Make bit manipulation value / round number and shift amount types for builtins unsigned

On 9/11/23 19:28, Tsukasa OI wrote: From: Tsukasa OI For bit manipulation operations, input(s) and the manipulated output are better to be unsigned like other target-independent builtins like __builtin_bswap32 and __builtin_popcount. Although this is not completely compatible as before (as

Re: [PATCH v1] RISC-V: Bugfix for scalar move with merged operand

On 9/17/23 01:42, Pan Li via Gcc-patches wrote: From: Pan Li Given below example for VLS mode void test (vl_t *u) { vl_t t; long long *p = (long long *) p[0] = p[1] = 2; *u = t; } The vec_set will simplify the insn to vmv.s.x when index is 0, without merged operand. That

Re: [pushed] [RA]: Improve cost calculation of pseudos with equivalences

On 9/14/23 09:28, Vladimir Makarov via Gcc-patches wrote: I've committed the following patch.  The reason for this patch is explained in its commit message. The patch was successfully bootstrapped and tested on x86-64, aarch64, and ppc64le.

Re: [PATCH] RISC-V: Finish Typing Un-Typed Instructions and Turn on Assert

On 9/12/23 00:18, Lehua Ding wrote: Hi Jeff, On 2023/9/12 11:47, Jeff Law wrote: But that condition is _not_ generally sufficient to prevent these insns from existing during sched1.  ie, a pass between split1 and sched1 could create these patterns and successfully match them.  That in

Re: [PATCH V4] RISC-V: Expand VLS mode to scalar mode move[PR111391]

On 9/14/23 16:26, 钟居哲 wrote: I don't think it can fix the case when it is -march=rv64gc_zve32x juzhe.zh...@rivai.ai *From:* Kito Cheng *Date:* 2023-09-15 00:17 *To:*

Re: [PATCH v1] RISC-V: Remove unused structure in cost model

On 9/12/23 07:02, Pan Li via Gcc-patches wrote: From: Pan Li The struct range is unused, remove it. gcc/ChangeLog: * config/riscv/riscv-vector-costs.h (struct range): Removed. OK jeff

Re: [PATCH] RISC-V: Finish Typing Un-Typed Instructions and Turn on Assert

On 9/11/23 21:17, Lehua Ding wrote: Hi Jeff, On 2023/9/12 11:00, Jeff Law wrote: I'd rather be consistent and make it policy that every insn has a type. Since the type set here will not be used by sched pass (these insn pattern will not exit at shced pass since use define_insn_and_split

Re: [PATCH v2 2/2] riscv: Add support for str(n)cmp inline expansion

On 9/6/23 10:07, Christoph Muellner wrote: From: Christoph Müllner This patch implements expansions for the cmpstrsi and cmpstrnsi builtins for RV32/RV64 for xlen-aligned strings if Zbb or XTheadBb instructions are available. The expansion basically emits a comparison sequence which

Re: [PATCH v2 1/2] riscv: Add support for strlen inline expansion

On 9/6/23 10:07, Christoph Muellner wrote: From: Christoph Müllner This patch implements the expansion of the strlen builtin for RV32/RV64 for xlen-aligned aligned strings if Zbb or XTheadBb instructions are available. The inserted sequences are: rv32gc_zbb (RV64 is similar): add

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

On 9/7/23 14:33, Palmer Dabbelt wrote: On Thu, 07 Sep 2023 13:16:36 PDT (-0700), dimi...@dinux.eu wrote: Hi, This patch appears to have caused PR 111259. Thanks.  Looks like wer'e not running our tests with RTL checking, Patrick is going to try and see if we've got compute time left for

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

On 9/7/23 19:26, Feng Wang wrote: Supported ISA specs (for use with the -misa-spec= option): diff --git a/gcc/opt-functions.awk b/gcc/opt-functions.awk index 36de4639318..cbfcf7dabcf 100644 --- a/gcc/opt-functions.awk +++ b/gcc/opt-functions.awk @@ -387,3 +387,14 @@ function

Re: [PATCH] RISC-V: Finish Typing Un-Typed Instructions and Turn on Assert

On 9/11/23 20:33, Lehua Ding wrote: Hi Edwin, Sorry to bother you. I have a small question for you. On 2023/9/12 6:52, Edwin Lu wrote: --- a/gcc/config/riscv/autovec-opt.md +++ b/gcc/config/riscv/autovec-opt.md @@ -649,7 +649,8 @@ (define_insn_and_split "*cond_" gen_int_mode

Re: RISC-V: Replace not + bitwise_imm with li + bitwise_not

On 9/11/23 13:16, Andrew Waterman via Gcc-patches wrote: Note this is a size-speed tradeoff, as the Zcb extension has a 16-bit-wide C.NOT instruction. Might want to suppress this optimization when Zcb is present and the function is being optimize > for size. Yea, let's gate this on

Re: [PATCH] RISC-V: Finish Typing Un-Typed Instructions and Turn on Assert

On 9/11/23 16:52, Edwin Lu wrote: Updates autovec instruction that was added after last patch and turns on the assert statement to ensure all new instructions have a type. * config/riscv/autovec-opt.md: Update type * config/riscv/riscv.cc (riscv_sched_variable_issue): Remove

Re: [PATCH v5] Implement new RTL optimizations pass: fold-mem-offsets.

On 9/9/23 02:46, Manolis Tsamis wrote: This is a new RTL pass that tries to optimize memory offset calculations by moving them from add immediate instructions to the memory loads/stores. For example it can transform this: addi t4,sp,16 add t2,a6,t4 shl t3,t2,1 ld a2,0(t3)

Re: [PATCH] RISC-V: Enable RVV scalable vectorization by default[PR111311]

On 9/10/23 21:42, juzhe.zh...@rivai.ai wrote: Ping this patch. I think it's time to enable scalable vectorization by default and do the whole regression every time (except vect.exp that we didn't enable yet) Update current FAILs status: Real FAILS (ICE and execution FAIL): FAIL:

Re: [PATCH] MATCH: [PR111346] `X CMP MINMAX` pattern missing :c on CMP

On 9/10/23 20:18, Andrew Pinski via Gcc-patches wrote: I noticed this while working on other MINMAX optimizations. It was hard to find a simplified testcase though because it was dependent on the ssa name versions. Adding the `:c` to cmp allows the pattern to be match for the case where

Re: [PATCH] Fix PR 111331: wrong code for `a > 28 ? MIN : 29`

On 9/8/23 06:39, Andrew Pinski via Gcc-patches wrote: The problem here is after r6-7425-ga9fee7cdc3c62d0e51730, the comparison to see if the transformation could be done was using the wrong value. Instead of see if the inner was LE (for MIN and GE for MAX) the outer value, it was comparing

Re: [PATCH] RISC-V Add Types to Un-Typed Thead Instructions:

On 8/31/23 11:36, Edwin Lu wrote: Related Discussion: https://inbox.sourceware.org/gcc-patches/12fb5088-3f28-0a69-de1e-f387371a5...@gmail.com/ This patch updates the THEAD instructions to ensure that no insn is left without a type attribute. Tested for regressions using rv32/64 multilib for

Re: [PATCH V2] RISC-V: Avoid unnecessary slideup in compress pattern of vec_perm

On 9/10/23 08:07, Juzhe-Zhong wrote: gcc/ChangeLog: * config/riscv/riscv-v.cc (shuffle_compress_patterns): Avoid unnecessary slideup. OK jeff

Re: [PATCH] RISC-V: Expand fixed-vlmax/vls vector permutation in targethook

On 9/9/23 20:33, Juzhe-Zhong wrote: When debugging FAIL: gcc.dg/pr92301.c execution test. Realize a vls vector permutation situation failed to vectorize since early return false: - /* For constant size indices, we dont't need to handle it here. - Just leave it to vec_perm. */ - if

Re: [PATCH] RISC-V: Avoid unnecessary slideup in compress pattern of vec_perm

On 9/9/23 21:55, Juzhe-Zhong wrote: If a const vector all elements are same, the slide up is unnecessary. gcc/ChangeLog: * config/riscv/riscv-v.cc (shuffle_compress_patterns): Avoid unnecessary slideup. --- gcc/config/riscv/riscv-v.cc | 2 +- 1 file changed, 1 insertion(+), 1

Re: [PATCH v2 2/5] RISC-V: Add Types for Un-Typed zc Instructions

On 9/8/23 12:16, Edwin Lu wrote: This patch adds types to the untyped zc instructions. Creates a new types "pushpop" and "mvpair" for now gcc/ChangeLog: * config/riscv/riscv.md: Add "csr" type * config/riscv/zc.md: Update types OK. Note that once we finish this exercise,

Re: [PATCH v2 1/5] RISC-V: Update Types for Vector Instructions

On 9/8/23 12:16, Edwin Lu wrote: This patch adds types to vector instructions that were added after or were missed by the original patch https://gcc.gnu.org/pipermail/gcc-patches/2023-August/628594.html gcc/ChangeLog: * config/riscv/autovec-opt.md: Update types *

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

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

Re: [PATCH 5/5] RISC-V: Remove Assert Protecting Types

On 9/6/23 11:50, Edwin Lu wrote: This patch turns on the assert which ensures every instruction has type that is not TYPE_UNKNOWN. gcc/ChangeLog: * config/riscv/riscv.cc (riscv_sched_variable_issue): Remove assert And this is fine. But hold off committing until all the dependencies

Re: [PATCH 3/5] RISC-V: Add Types to Un-Typed Zicond Instructions

On 9/6/23 18:42, Tsukasa OI via Gcc-patches wrote: Looks okay to me but will need to resolve merge conflicts after commit af88776caa20 ("RISC-V: Add support for 'XVentanaCondOps' reusing 'Zicond' support"). Sure. We allow trival updates to resolve merge conflicts without needing another

Re: [PATCH v2 1/2] riscv: Add support for strlen inline expansion

On 9/6/23 10:22, Palmer Dabbelt wrote: On Wed, 06 Sep 2023 09:07:33 PDT (-0700), christoph.muell...@vrull.eu wrote: From: Christoph Müllner This patch implements the expansion of the strlen builtin for RV32/RV64 for xlen-aligned aligned strings if Zbb or XTheadBb instructions are

Re: [PATCH v4 1/1] RISC-V: Add support for 'XVentanaCondOps' reusing 'Zicond' support

On 9/5/23 23:47, Tsukasa OI wrote: From: Tsukasa OI 'XVentanaCondOps' is a vendor extension from Ventana Micro Systems containing two instructions for conditional move and will be supported on their Veyron V1 CPU. And most notably (for historical reasons), 'XVentanaCondOps' and the

Re: [PATCH] RISC-V: Fix incorrect mode tieable which cause ICE in RA[PR111296]

On 9/6/23 03:47, Juzhe-Zhong wrote: This patch fix incorrect mode tieable between DI and V2SI which cause ICE in RA. PR target/111296 gcc/ChangeLog: * config/riscv/riscv.cc (riscv_modes_tieable_p): Fix bug. gcc/testsuite/ChangeLog: *

Re: [PATCH v3 1/1] RISC-V: Add support for 'XVentanaCondOps' reusing 'Zicond' support

On 9/5/23 20:33, Tsukasa OI wrote: Internally we have this as: (TARGET_ZICOND || TARGET_XVENTANACONDOPS) I don't really care, so I'm happy to go with yours. Because XVentanaCondOps instructions are only available on 64-bit target (I wanted to prevent misuses because we don't reject

Re: [PATCH v2] RISC-V: Fix Zicond ICE on large constants

On 9/5/23 06:08, Tsukasa OI wrote: From: Tsukasa OI Large constant cons and/or alt will trigger ICEs building GCC target libraries (libgomp and libatomic) when the 'Zicond' extension is enabled. For instance, zicond-ice-2.c (new test case in this commit) will cause an ICE when SOME_NUMBER

Re: [PATCH] RISC-V: Add conditional sqrt autovec pattern

On 9/3/23 22:49, Lehua Ding wrote: This patch adds a combined pattern for combining vfsqrt.v and vcond_mask. gcc/ChangeLog: * config/riscv/autovec-opt.md (*cond_): Add sqrt + vcond_mask combine pattern. * config/riscv/autovec.md (2): Change define_expand to

Re: [PATCH v3 1/1] RISC-V: Add support for 'XVentanaCondOps' reusing 'Zicond' support

On 9/5/23 06:10, Tsukasa OI wrote: From: Tsukasa OI 'XVentanaCondOps' is a vendor extension from Ventana Micro Systems containing two instructions for conditional move and will be supported on their Veyron V1 CPU. And most notably (for historical reasons), 'XVentanaCondOps' and the

Re: [PATCH] riscv: Synthesize all 11-bit-rotate constants with rori

On 9/5/23 15:15, Christoph Muellner wrote: From: Christoph Müllner Some constants can be built up using LI+RORI instructions. The current implementation requires one of the upper 32-bits to be a zero bit, which is not neccesary. Let's drop this requirement in order to be able to synthesize

Re: [PATCH V2] RISC-V: Support Dynamic LMUL Cost model

On 9/5/23 15:39, 钟居哲 wrote: - Why don't we use the normal reverse postorder (or postorder) approach of    computing live ranges?  Is that because we don't really need full global    live ranges? Yes. We don't need global live ranges. - Why can't we use existing code i.e. tree-ssa-live?  I

[committed] RISC-V: Expose bswapsi for TARGET_64BIT

Various bswapsi tests are failing for rv64. More importantly, we're generating crappy code. Let's take the first test from bswapsi-1.c as an example. typedef unsigned int uint32_t; #define __const_swab32(x) ((uint32_t)(\ (((uint32_t)(x) &

Re: [PATCH] riscv: xtheadbb: Enable constant synthesis with th.srri

On 9/5/23 09:42, Christoph Muellner wrote: From: Christoph Müllner Some constants can be built up using rotate-right instructions. The code that enables this can be found in riscv_build_integer_1(). However, this functionality is only available for Zbb, which includes the rori instruction.

Re: [PATCH] MATCH: `(nop_convert)-(convert)a` into -(convert)a if we are converting from something smaller

On 9/2/23 01:00, Andrew Pinski via Gcc-patches wrote: This allows removal of one conversion and in the case of booleans, might be able to remove the negate and the other conversion later on. OK? Bootstrapped and tested on x86_64-linux-gnu with no regressions. PR

Re: [PATCH] MATCH: Add `(x | c) & ~(y | c)` and `x & ~(y | x)` patterns [PR98710]

On 9/3/23 19:25, Andrew Pinski via Gcc-patches wrote: Adding some more simple bit_and/bit_ior patterns. How often these show up, I have no idea. This was tested on top of https://gcc.gnu.org/pipermail/gcc-patches/2023-September/629174.html . OK? Bootstrapped and tested on x86_64-linux-gnu

Re: [PATCH] MATCH: Add pattern for `(x | y) & (x & z)`

On 9/3/23 14:49, Andrew Pinski via Gcc-patches wrote: Like the pattern already there for `(x | y) & x`, this adds a simple pattern to optimize `(x | y) & (x & z)` to just `x & z`. OK? Bootstrapped and tested on x86-64-linux-gnu with no regressions. gcc/ChangeLog: PR

Re: [PATCH] RISC-V: Emit .note.GNU-stack for non-linux target as well

On 8/31/23 03:05, Kito Cheng wrote: We only emit that on linux target before, that not problem before, however Qemu has fix a bug to make qemu user mode honor PT_GNU_STACK[1], that will cause problem when we test baremetal with qemu. So the straightforward is enable that as well for

Re: [PATCH] MATCH: Add `~MAX(~X, Y)` pattern: [PR96694]

On 9/3/23 18:21, Andrew Pinski via Gcc-patches wrote: This adds `~MAX(~X, Y)` and `~MIN(~X, Y)` patterns that are like the `~(~a & b)` and `~(~a | b)` patterns and allows to reduce the number of ~ by 1. OK? Bootstrapped and tested on x86_64-linux-gnu with no regressions. PR

Re: [PATCH] MATCH: Transform `(1 >> X) !=/== 0` into `X ==/!= 0`

On 9/3/23 10:25, Andrew Pinski via Gcc-patches wrote: We currently have a pattern for handling `(C >> X) & D == 0` but if C is 1 and D is 1, the `& 1` might have been removed. gcc/ChangeLog: PR tree-optimization/105832 * match.pd (`(1 >> X) != 0`): New pattern OK jeff

Re: [PATCH] ssa_name_has_boolean_range vs signed-boolean:31 types

On 9/1/23 20:32, Andrew Pinski via Gcc-patches wrote: This turns out to be a latent bug in ssa_name_has_boolean_range where it would return true for all boolean types but all of the uses of ssa_name_has_boolean_range was expecting 0/1 as the range rather than [-1,0]. So when I fixed vector

Re: [PATCH 3/3] MATCH: Replace all uses of ssa_name_has_boolean_range with zero_one_valued_p

On 9/2/23 09:09, Andrew Pinski via Gcc-patches wrote: This replaces all uses of ssa_name_has_boolean_range with zero_one_valued_p except for the one in the definition of zero_one_valued_p. This simplifies the code in general and makes only one way of saying we have a range of [0,1]. Note

Re: [PATCH 2/3] MATCH: Improve zero_one_valued_p by using ssa_name_has_boolean_range

On 9/2/23 09:09, Andrew Pinski via Gcc-patches wrote: Currently zero_one_valued_p uses tree_nonzero_bits which uses the global ranges of the SSA Names. We can improve this via using ssa_name_has_boolean_range which uses the local ranges which are used while handling folding during VRP and

Re: [PATCH 1/3] Improve ssa_name_has_boolean_range slightly

On 9/2/23 09:09, Andrew Pinski via Gcc-patches wrote: Right now ssa_name_has_boolean_range compares the range to range_true_and_false but instead we would get the nonzero bits and compare that to 1 instead (<=u 1). The nonzerobits comparison can be done in similar fashion. Note I think

Re: [PATCH] riscv: xtheadcondmov: Don't run tests with -Oz

On 9/1/23 04:20, Christoph Muellner wrote: From: Christoph Müllner Recently, these xtheadcondmov tests regressed with -Oz: * FAIL: gcc.target/riscv/xtheadcondmov-mveqz-imm-eqz.c * FAIL: gcc.target/riscv/xtheadcondmov-mveqz-imm-not.c * FAIL: gcc.target/riscv/xtheadcondmov-mvnez-imm-cond.c *

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

On 9/1/23 11:30, Andrew Pinski via Gcc-patches wrote: So it turns out there was a simplier way of starting to improve VRP to start to fix PR 110131, PR 108360, and PR 108397. That was rewrite test_for_singularity to use range_op_handler and Value_Range. This patch implements that and OK?

Re: [PATCH 1/2] VR-VALUES: Rename op0/op1 to op1/op2 for test_for_singularity

On 9/1/23 11:30, Andrew Pinski via Gcc-patches wrote: As requested and make easier to understand with the new ranger code, rename the arguments op0/op1 to op1/op2. OK? Bootstrapped and tested on x86_64-linux-gnu with no regressions gcc/ChangeLog: * vr-values.cc

Re: [PATCH v2] RISC-V: zicond: Fix opt2 pattern

On 9/4/23 20:19, Tsukasa OI wrote: -FAIL: 30_threads/async/async.cc execution test +FAIL: gcc.c-torture/execute/pr60003.c -O1 execution test +FAIL: gcc.dg/setjmp-3.c execution test +FAIL: gcc.dg/torture/stackalign/setjmp-3.c -O1 execution test +FAIL:

Re: [PATCH] RISC-V: Fix Zicond ICE on large constants

On 9/4/23 00:45, Kito Cheng wrote: Maybe move the check logic a bit forward? My thought is the logic is already specialized into a few catalogs, (imm, imm), (imm, reg), (reg, reg)... and the logic you put is already in (imm, reg), but it should really move into (reg, reg) case IMO? and move

Re: [PATCH v2 1/2] strlen: fold strstr() even if the length isn't previously known [PR96601]

On 9/4/23 14:58, Hamza Mahfooz wrote: Currently, we give up in fold_strstr_to_strncmp() if the length of the the second argument to strstr() isn't known to us by the time we hit that function. However, we can instead insert a strlen() in ourselves and continue trying to fold strstr() into

Re: [PATCH] lra: Avoid unfolded plus-0

On 8/31/23 09:24, Richard Sandiford via Gcc-patches wrote: While backporting another patch to an earlier release, I hit a situation in which lra_eliminate_regs_1 would eliminate an address to: (plus (reg:P R) (const_int 0)) This address compared not-equal to plain: (reg:P R)

Re: [PATCH] RISC-V: Document some -march special cases

On 8/29/23 23:52, Kito Cheng wrote: I would prefer NOT to expose those --param on user manual since generally those options are used for internal only, we should add -m option and enable `--param=riscv-autovec-preference=scalable` by default once we think it's stable enough. I tend to agree.

Re: [PATCH v2] RISC-V: zicond: Fix opt2 pattern

On 9/1/23 13:53, Vineet Gupta wrote: This was tripping up gcc.c-torture/execute/pr60003.c at -O1 since in failing case, pattern's asm czero.nez gets both rs2 and rs1 as non zero. We start with the following src code snippet: if (a == 0) return 0; else return x;

Re: [PATCH] RISC-V: Add Types to Un-Typed Risc-v Instructions:

On 8/31/23 11:32, Edwin Lu wrote: Related Discussion: https://inbox.sourceware.org/gcc-patches/12fb5088-3f28-0a69-de1e-f387371a5...@gmail.com/ This patch updates the riscv instructions to ensure that no insn is left without a type attribute. Added new types: "trap" (self explanatory) and

Re: [PATCH] Add Types to Un-Typed Pic Instructions:

On 8/31/23 17:01, Edwin Lu wrote: Related Discussion: https://inbox.sourceware.org/gcc-patches/12fb5088-3f28-0a69-de1e-f387371a5...@gmail.com/ This patch updates the pic instructions to ensure that no insn is left without a type attribute. Tested for regressions using rv32/64 multilib with

Re: [PATCH] RISC-V: zicond: remove bogus opt2 pattern

On 8/31/23 11:57, Vineet Gupta wrote: On 8/31/23 06:51, Jeff Law wrote: On 8/30/23 15:57, Vineet Gupta wrote: This was tripping up gcc.c-torture/execute/pr60003.c at -O1 since the pattern semantics can't be expressed by zicond instructions. This involves test code snippet:    if

Re: [PATCH] RISC-V: zicond: remove bogus opt2 pattern

On 8/30/23 15:57, Vineet Gupta wrote: This was tripping up gcc.c-torture/execute/pr60003.c at -O1 since the pattern semantics can't be expressed by zicond instructions. This involves test code snippet: if (a == 0) return 0; else return x; } which is

Re: [PATCH] RISC-V: Make arch-24.c to test "success" case

On 8/28/23 21:31, Tsukasa OI wrote: From: Tsukasa OI arch-24.c and arch-25.c are exactly the same and redundant. The author suspects that the original author intended to test two base ISAs (RV32I and RV64I) so this commit changes arch-24.c to test that RV32I+Zcf does not cause any errors.

Re: [PATCH] RISC-V: Added zvfh support for zfa extensions.

On 8/29/23 01:51, Jin Ma wrote: This is a follow-up for the zfa extension, added according to the recommendations for zvfh and patch of Tsukasa OI. At the same time, zfa-fli-5.c of which is also based on the patch. Ref: https://gcc.gnu.org/pipermail/gcc-patches/2023-August/627284.html

Re: [PATCH] RISC-V: Enable movmisalign for VLS modes

On 8/29/23 07:54, Kito Cheng via Gcc-patches wrote: +/* To support misalign data movement, we should use + minimum element alignment load/store. */ +unsigned int size = GET_MODE_SIZE (GET_MODE_INNER (mode)); +poly_int64 nunits = GET_MODE_NUNITS (mode) * size; +

Re: [PATCH] RISC-V: Remove movmisalign pattern for VLA modes

On 8/29/23 03:39, Juzhe-Zhong wrote: This patch fixed this bunch of failures in "vect" testsuite: FAIL: gcc.dg/vect/pr63341-1.c -flto -ffat-lto-objects execution test FAIL: gcc.dg/vect/pr63341-1.c execution test FAIL: gcc.dg/vect/pr63341-2.c -flto -ffat-lto-objects execution test FAIL:

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

On 8/28/23 20:09, Tsukasa OI wrote: On 2023/08/29 6:20, Jeff Law wrote: On 8/9/23 21:10, Tsukasa OI via Gcc-patches wrote: From: Tsukasa OI The "__builtin_riscv_zicbop_cbo_prefetchi" built-in function was terribly broken so that practically unusable.  It emitted "prefetch.i" but with no

Re: [PATCH v2] RISC-V: Make PR 102957 tests more comprehensive

On 8/28/23 21:28, Tsukasa OI wrote: From: Tsukasa OI Commit c283c4774d1c ("RISC-V: Throw compilation error for unknown extensions") changed how do we handle unknown extensions and commit 6f709f79c915a ("[committed] [RISC-V] Fix expected diagnostic messages in testsuite") "fixed" test

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

On 8/28/23 21:39, Tsukasa OI wrote: From: Tsukasa OI After commit c283c4774d1c ("RISC-V: Throw compilation error for unknown extensions") changed how do we handle unknown extensions, we have no guarantee that we can share the same architectural string with Binutils (specifically, the

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

On 8/28/23 21:39, Tsukasa OI wrote: From: Tsukasa OI After commit c283c4774d1c ("RISC-V: Throw compilation error for unknown extensions") changed how do we handle unknown extensions, we have no guarantee that we can share the same architectural string with Binutils (specifically, the

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

On 8/28/23 21:39, Tsukasa OI wrote: From: Tsukasa OI After commit c283c4774d1c ("RISC-V: Throw compilation error for unknown extensions") changed how do we handle unknown extensions, we have no guarantee that we can share the same architectural string with Binutils (specifically, the

Re: [PATCH] [tree-optimization/110279] swap operands in reassoc to reduce cross backedge FMA

On 8/29/23 01:41, Richard Biener wrote: _1 = a * b; _2 = .FMA (c, d, _1); acc_1 = acc_0 + _2; How can we execute the multiply and the FMA in parallel? They depend on each other. Or is it the uarch can handle dependence on the add operand but only when it is with a

Re: [PATCH 1/2] allow targets to check shrink-wrap-separate enabled or not

On 8/28/23 19:28, Fei Gao wrote: On 2023-08-29 06:54  Jeff Law wrote: On 8/28/23 01:47, Fei Gao wrote: no functional changes but allow targets to check shrink-wrap-separate enabled or not.     gcc/ChangeLog:   * shrink-wrap.cc (try_shrink_wrapping_separate):call    

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

On 8/14/23 00:09, Tsukasa OI wrote: From: Tsukasa OI After commit c283c4774d1c ("RISC-V: Throw compilation error for unknown extensions") changed how do we handle unknown extensions, we have no guarantee that we can share the same architectural string with Binutils (specifically, the

Re: [PATCH] mklog: fix bugs of --append option

On 7/19/23 02:21, Lehua Ding wrote: Hi, This little patch fix two bugs of mklog.py with --append option. The first bug is that the regexp used is not accurate enough to determine the top of diff area. The second bug is that if `---` is not a true start, it needs to be added back to the patch

Re: [PATCH] fwprop: Allow UNARY_P and check register pressure.

On 8/24/23 08:06, Robin Dapp via Gcc-patches wrote: Ping. I refined the code and some comments a bit and added a test case. My question in general would still be: Is this something we want given that we potentially move some of combine's work a bit towards the front of the RTL pipeline?

Re: [PATCH] [tree-optimization/110279] swap operands in reassoc to reduce cross backedge FMA

On 8/28/23 02:17, Di Zhao OS via Gcc-patches wrote: This patch tries to fix the 2% regression in 510.parest_r on ampere1 in the tracker. (Previous discussion is here: https://gcc.gnu.org/pipermail/gcc-patches/2023-July/624893.html) 1. Add testcases for the problem. For an op list in the form

Re: [RFC PATCH 2/2] RISC-V: Fix documentation of __builtin_riscv_pause

On 8/28/23 17:09, Hans-Peter Nilsson wrote: On Mon, 28 Aug 2023, Jeff Law via Gcc-patches wrote: On 8/9/23 00:11, Tsukasa OI via Gcc-patches wrote: From: Tsukasa OI This built-in does not imply the 'Xgnuzihintpausestate' extension. It does not change architectural state (because all

Re: [PATCH 1/2] allow targets to check shrink-wrap-separate enabled or not

On 8/28/23 01:47, Fei Gao wrote: no functional changes but allow targets to check shrink-wrap-separate enabled or not. gcc/ChangeLog: * shrink-wrap.cc (try_shrink_wrapping_separate):call use_shrink_wrapping_separate. (use_shrink_wrapping_separate): wrap the

Re: [PATCH V3] riscv: generate builtin macro for compilation with strict alignment:

On 8/15/23 12:29, Edwin Lu wrote: This patch is a modification of https://gcc.gnu.org/pipermail/gcc-patches/2023-January/610115.html following the discussion on https://github.com/riscv-non-isa/riscv-c-api-doc/issues/32 Distinguish between explicit -mstrict-align and cpu tune param for

Re: [PATCH 1/2] allow target to check shrink-wrap-separate enabled or not

On 6/25/23 20:29, Fei Gao wrote: hi Jeff Please see my earlier reply here. https://www.mail-archive.com/gcc-patches@gcc.gnu.org/msg310656.html Maybe you scrolled past it in so many emails:) Oh, so the issue isn't really the set of components being wrapped, but the way in which we save

Re: [PATCH 1/2] allow target to check shrink-wrap-separate enabled or not

On 6/25/23 20:29, Fei Gao wrote: hi Jeff Please see my earlier reply here. https://www.mail-archive.com/gcc-patches@gcc.gnu.org/msg310656.html Maybe you scrolled past it in so many emails:) It definitely got lost in my mountain of mail. jeff

Re: [PATCH] RISC-V: Revive test case PR 102957

On 8/11/23 08:29, Tsukasa OI wrote: On 2023/08/11 23:15, Jeff Law wrote: Originally, it tested that a two letter extension ('Zb') is accepted by GCC (because the background of PR 102957 was GCC assumed multi-letter 'Z' extensions are three letters or more). After rejecting unrecognized

Re: [PATCH] RISC-V: Add Types to Un-Typed Vector Instructions:

On 8/28/23 13:03, Edwin Lu wrote: Related Discussion: https://inbox.sourceware.org/gcc-patches/12fb5088-3f28-0a69-de1e-f387371a5...@gmail.com/ This patch updates vector instructions to ensure that no insn is left without a type attribute. Creates a placeholder type "vector" for insns where a

Re: [PATCH V2] RISC-V: Fix error combine of pred_mov pattern

On 8/10/23 06:21, Lehua Ding wrote: +;; vle.v/vse.v,vmv.v.v +(define_insn_and_split "*pred_mov" + [(set (match_operand:V_VLS 0 "nonimmediate_operand""=vr,vr, vd, m,vr,vr") +(if_then_else:V_VLS + (unspec: +[(match_operand: 1

Re: [PATCH] RISC-V: Fix error combine of pred_mov pattern

On 8/11/23 10:30, Lehua Ding wrote: > But combine doesn't run at -O0.  So something is inconsistent.  I > certainly believe we need to avoid the mem->mem case, but that's > independent of combine and affects all optimization levels. This is an new bug when running all tests after fixing

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

On 8/9/23 21:10, Tsukasa OI via Gcc-patches wrote: From: Tsukasa OI The "__builtin_riscv_zicbop_cbo_prefetchi" built-in function was terribly broken so that practically unusable. It emitted "prefetch.i" but with no meaningful arguments. Though incompatible, this commit completely changes

Re: [RFC PATCH 2/2] RISC-V: Fix documentation of __builtin_riscv_pause

On 8/9/23 00:11, Tsukasa OI via Gcc-patches wrote: From: Tsukasa OI This built-in does not imply the 'Xgnuzihintpausestate' extension. It does not change architectural state (because all HINTs are prohibited from doing that). gcc/ChangeLog: * doc/extend.texi: Fix the description

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

On 8/9/23 00:11, Tsukasa OI via Gcc-patches wrote: From: Tsukasa OI The "pause" RISC-V hint instruction requires the 'Zihintpause' extension (in the assembler). However, GCC emits "pause" unconditionally, making an assembler error while compiling code with __builtin_riscv_pause while the

Re: [PATCH V4] RISC-V: Enable vec_int testsuite for RVV VLA vectorization

On 8/28/23 08:27, Robin Dapp via Gcc-patches wrote: LGTM from my side, but I would like to wait Robin is ok too In principle I'm OK with it as well, realizing we will still need to fine-tune a lot here anyway. For now, IMHO it's good to have some additional test coverage in the vector

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

On 8/13/23 23:50, Jin Ma wrote: This patch adds the 'Zfa' extension for riscv, which is based on: https://github.com/riscv/riscv-isa-manual/commits/zfb The binutils-gdb for 'Zfa' extension: https://sourceware.org/pipermail/binutils/2023-April/127060.html What needs special explanation is:

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

On 8/14/23 06:51, Jin Ma wrote: This code is great and completely different from the way I implemented it. I'm not sure which one is better, but my idea is that the fli instruction corresponds to three tables (HF, SF and DF), all of which represent specific values. the library in gcc's

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

On 8/13/23 23:32, Tsukasa OI via Gcc-patches wrote: From: Tsukasa OI This commit adds support for the 'Zfa' extension containing additional floating point instructions, version 0.1 (stable and approved). gcc/ChangeLog: * common/config/riscv/riscv-common.cc

Re: [PATCH V2] RISC-V: Add Types to Un-Typed Sync Instructions:

On 8/24/23 15:19, Edwin Lu wrote: Related Discussion: https://inbox.sourceware.org/gcc-patches/12fb5088-3f28-0a69-de1e-f387371a5...@gmail.com/ This patch updates the sync instructions to ensure that no insn is left without a type attribute. Updates a total of 6 insns to have type "atomic"

Re: [PATCH v2] RISC-V: Enable Hoist to GCSE simple constants

On 8/24/23 23:16, Vineet Gupta wrote: Hoist want_to_gcse_p () calls rtx_cost () to compute max distance for hoist candidates. For a simple const (say 6 which needs seperate insn "LI 6") backend currently returns 0, causing Hoist to bail and elide GCSE. Note that constants requiring more than

Re: RISC-V: Fix stack_save_restore_1/2 test cases

On 8/24/23 09:45, Jivan Hakobyan via Gcc-patches wrote: Subject: RISC-V: Fix stack_save_restore_1/2 test cases From: Jivan Hakobyan via Gcc-patches Date: 8/24/23, 09:45 To: GCC Patches , Jeff Law This patch fixes failing stack_save_restore_1/2 test cases. After 6619b3d4c15c commit size

  1   2   3   4   5   6   7   8   9   10   >