ubreg
coalesce functionality. Support for subreg coalesce requires support for
subreg copy i.e. modifying the logic for conflict detection.
On 2024/5/2 00:24, Vladimir Makarov wrote:
On 2/3/24 05:50, Lehua Ding wrote:
This patch apply the DF_LIVE_SUBREG to LRA pass. More changes were made
t
Hi Dimitar,
Thanks for helping to review the code! I will send V3 patch which
address these comments.
Best,
Lehua
On 2024/4/26 04:56, Dimitar Dimitrov wrote:
On Wed, Apr 24, 2024 at 06:05:03PM +0800, Lehua Ding wrote:
This patch add a new DF problem, named DF_LIVE_SUBREG. This problem
s));
+}
+
+/* Verify bitmap_same_p functions for sbitmap. */
+
+static void
+test_same ()
+{
+ sbitmap s1 = sbitmap_alloc (193);
+ sbitmap s2 = sbitmap_alloc (193);
+ sbitmap s3 = sbitmap_alloc (192);
+
+ ASSERT_FALSE (bitmap_same_p (s1, s3));
+
+ bitmap_clear (s1);
+ bitmap_clear (s2);
This patch apply the DF_LIVE_SUBREG to LRA pass. More changes were made
to the LRA than the IRA since the LRA will modify the DF data directly.
The main big changes are centered on the lra-lives.cc file.
gcc/ChangeLog:
* lra-coalesce.cc (update_live_info): Extend to DF_LIVE_SUBREG.
This patch simple replace df_get_live_in to df_get_subreg_live_in
and replace df_get_live_out to df_get_subreg_live_out.
gcc/ChangeLog:
* ira-build.cc (create_bb_allocnos): Switch to DF_LIVE_SUBREG df data.
(create_loop_allocnos): Ditto.
* ira-color.cc (ira_loop_edge_freq)
Add new flag -ftrack-subreg-liveness to enable track-subreg-liveness.
This flag is enabled at -O3/fast.
gcc/ChangeLog:
* common.opt: add -ftrack-subreg-liveness option.
* opts.cc: auto aneble -ftrack-subreg-liveness in -O3/fast
---
gcc/common.opt | 4
gcc/common.opt.url
03947520, very small increase.
No regression on x86-64
Co-authored-by: Shuo Chen
Best,
Lehua
Lehua Ding (4):
df: Add -ftrack-subreg-liveness option
df: Add DF_LIVE_SUBREG problem
ira: Apply DF_LIVE_SUBREG data
lra: Apply DF_LIVE_SUBREG data
gcc/Makefile.in | 1 +
gcc/common
On 2024/2/6 2:17, Joseph Myers wrote:
This series appears to be missing documentation for the new option in
invoke.texi.
OK, I'll add that. Thanks.
--
Best,
Lehua (RiVAI)
On 2024/2/6 0:10, Jeff Law wrote:
Just a note. I doubt this will get much traction from a review
standpoint until gcc-14 is basically out the door.
My recommendation is to continue development, bugfixing, cleanup, etc
between now and then. Consider creating a branch for the work in the
up
For SPEC INT 2017, when using upstream GCC (whitout these patches), I get a
coredump when training the peak case, so no data yet. The cause of the core
dump still needs to be investigated.
Typo, SPEC INT 2017 -> SPEC FP 2017
Also There is a bad news, the score of specint 2017 (with these patches
This patch simple replace df_get_live_in to df_get_subreg_live_in
and replace df_get_live_out to df_get_subreg_live_out.
gcc/ChangeLog:
* ira-build.cc (create_bb_allocnos): Switch to DF_LIVE_SUBREG df data.
(create_loop_allocnos): Ditto.
* ira-color.cc (ira_loop_edge_freq)
This patch apply the DF_LIVE_SUBREG to LRA pass. More changes were made
to the LRA than the IRA since the LRA will modify the DF data directly.
The main big changes are centered on the lra-lives.cc file.
gcc/ChangeLog:
* lra-coalesce.cc (update_live_info): Extend to DF_LIVE_SUBREG.
s));
+}
+
+/* Verify bitmap_same_p functions for sbitmap. */
+
+static void
+test_same ()
+{
+ sbitmap s1 = sbitmap_alloc (193);
+ sbitmap s2 = sbitmap_alloc (193);
+ sbitmap s3 = sbitmap_alloc (192);
+
+ ASSERT_FALSE (bitmap_same_p (s1, s3));
+
+ bitmap_clear (s1);
+ bitmap_clear (s2);
s to be investigated.
No regression on x86-64, AArch64 and RISC-V target.
Best,
Lehua
Lehua Ding (4):
df: Add -ftrack-subreg-liveness option
df: Add DF_LIVE_SUBREG problem
ira: Apply DF_LIVE_SUBREG data
lra: Apply DF_LIVE_SUBREG data
gcc/Makefile.in | 1 +
gcc/common.opt
Add new flag -ftrack-subreg-liveness to enable track-subreg-liveness.
This flag is enabled at -O3/fast.
gcc/ChangeLog:
* common.opt: add -ftrack-subreg-liveness option.
* opts.cc: auto aneble -ftrack-subreg-liveness in -O3/fast
---
gcc/common.opt | 4
gcc/opts.cc| 1 +
Hi Richard,
On 2023/11/21 4:11, Richard Sandiford wrote:
Lehua Ding writes:
This patch adds a live_subreg problem to extend the original live_reg to
track the liveness of subreg. We will only try to trace speudo registers
who's mode size is a multiple of nature size and eventually a
On 2023/11/18 16:24, Sam James wrote:
Lehua Ding writes:
Hi Sam,
On 2023/11/18 16:06, Sam James wrote:
Lehua Ding writes:
Hi Vladimir,
On 2023/11/17 22:05, Vladimir Makarov wrote:
On 11/16/23 21:06, Lehua Ding wrote:
Hi Vladimir,
Thank you so much for your review. Based on your
Hi Sam,
On 2023/11/18 16:06, Sam James wrote:
Lehua Ding writes:
Hi Vladimir,
On 2023/11/17 22:05, Vladimir Makarov wrote:
On 11/16/23 21:06, Lehua Ding wrote:
Hi Vladimir,
Thank you so much for your review. Based on your comments, I feel
like there are a lot of issues, especially the
Hi Vladimir,
On 2023/11/17 22:05, Vladimir Makarov wrote:
On 11/16/23 21:06, Lehua Ding wrote:
Hi Vladimir,
Thank you so much for your review. Based on your comments, I feel like
there are a lot of issues, especially the long compile time issue. So
I'm going to reorganize and refacto
for
excess errors)
These cases failed on non-linux toolchain, but pass on linux toolchain.
This consistency is caused by your previous multilib patch as Lehua said:
https://github.com/gcc-mirror/gcc/commit/17d683d
____
juzhe.zh...@rivai.ai
From: Lehua Ding
Date: 202
ta to ira
4.2 lra: Apply live_subreg data to lra
4.3 ira: Support subreg liveness track
4.4 lra: Support subreg liveness track
So for the two patches about LRA, maybe you can stop review and wait for
the revised patchs.
On 2023/11/17 5:13, Vladimir Makarov wrote:
On 11/12/23 07:08,
On 2023/11/15 7:22, Peter Bergner wrote:
On 11/12/23 6:08 AM, Lehua Ding wrote:
V3 Changes:
1. fix three ICE.
2. rebase
I tested this on powerpc64le-linux and powerpc64-linux. The LE build
bootstrapped fine and it looks like only one testsuite FAIL which I have
to look into why
On 2023/11/14 0:43, Dimitar Dimitrov wrote:
On Sun, Nov 12, 2023 at 08:08:10PM +0800, Lehua Ding wrote:
V3 Changes:
1. fix three ICE.
2. rebase
Hi,
These patchs try to support subreg coalesce feature in
register allocation passes (ira and lra).
Hi Lehua,
V3 indeed fixes the arm
Committed, thanks Hongtao.
On 2023/11/14 18:24, Hongtao Liu wrote:
On Tue, Nov 14, 2023 at 5:01 PM Lehua Ding wrote:
Hi,
This little patch adjust the assert in apx-spill_to_egprs-1.c testcase.
The -mapxf compilation option allows more registers to be used, which in
turn eliminates the need
Hi,
This little patch adjust the assert in apx-spill_to_egprs-1.c testcase.
The -mapxf compilation option allows more registers to be used, which in
turn eliminates the need for local variables to be stored in stack memory.
Therefore, the assertion is changed to detects no memory loaded through th
On 2023/11/14 16:14, Richard Biener wrote:
On Mon, Nov 13, 2023 at 11:39 PM Vladimir Makarov wrote:
On 11/12/23 07:08, Lehua Ding wrote:
This patch adds a live_subreg problem to extend the original live_reg to
track the liveness of subreg. We will only try to trace speudo registers
who
Hi Vladimir,
On 2023/11/14 3:37, Vladimir Makarov wrote:
On 11/12/23 07:08, Lehua Ding wrote:
V3 Changes:
1. fix three ICE.
2. rebase
Hi,
These patchs try to support subreg coalesce feature in
register allocation passes (ira and lra).
I've started review of v3 patches and here
Hi Kito,
On 2023/11/13 19:13, Lehua Ding wrote:
Hi Robin,
On 2023/11/13 18:33, Robin Dapp wrote:
On 2023/11/13 18:22, juzhe.zh...@rivai.ai wrote:
If there is a difference between them. I think we should fix
riscv-common.cc.
Since I think "zvfh_zfh" should not be different with
Hi Robin,
On 2023/11/13 18:33, Robin Dapp wrote:
On 2023/11/13 18:22, juzhe.zh...@rivai.ai wrote:
If there is a difference between them. I think we should fix riscv-common.cc.
Since I think "zvfh_zfh" should not be different with "zfh_zvfh"
It's possible. Let me debug it and see if there's a
On 2023/11/13 18:33, Robin Dapp wrote:
On 2023/11/13 18:22, juzhe.zh...@rivai.ai wrote:
If there is a difference between them. I think we should fix riscv-common.cc.
Since I think "zvfh_zfh" should not be different with "zfh_zvfh"
It's possible. Let me debug it and see if there's a problem.
On 2023/11/13 18:22, juzhe.zh...@rivai.ai wrote:
If there is a difference between them. I think we should fix
riscv-common.cc.
Since I think "zvfh_zfh" should not be different with "zfh_zvfh"
It's possible. Let me debug it and see if there's a problem.
--
Best,
Lehua (RiVAI)
lehua.d...@riva
On 2023/11/13 17:59, Robin Dapp wrote:
Hi Lehua,
Executing on host:
/work/home/lding/open-source/riscv-gnu-toolchain-push/build/dev-rv64gcv_zvfh_zfh-lp64d-medany-newlib-spike-debug/build-gcc-newlib-stage2/gcc/xgcc
-B/work/home/lding/open-source/riscv-gnu-toolchain-push/build/dev-rv64gcv_z
Hi Robin,
Can you show me the compile command in gcc.log for the
slp-mask-run-1.exe like bellow? I'd like to see the -march option on
your side.
Executing on host:
/work/home/lding/open-source/riscv-gnu-toolchain-push/build/dev-rv64gcv_zvfh_zfh-lp64d-medany-newlib-spike-debug/build-gcc-newli
On 2023/11/13 9:11, juzhe.zh...@rivai.ai wrote:
Ah, nice! How configurable are the bit ranges?
I think Lehua's patch is configurable for bit ranges.
Since his patch allow target flexible tracking subreg livenesss
according to REGMODE_NATURAL_SIZE
+/* Return true if REGNO is a pseudo and M
Hi Vladimir,
While you're starting your review, please review v3 version that fixes
some ICE issues, thanks.
https://gcc.gnu.org/pipermail/gcc-patches/2023-November/636178.html
On 2023/11/12 20:01, Lehua Ding wrote:
Hi Vladimir,
On 2023/11/10 4:24, Vladimir Makarov wrote:
On 11/7/
This patch supports tracking the liveness of a subreg in a lra pass, with the
goal of getting it to agree with ira's register allocation scheme. There is some
duplication, maybe in the future this part of the code logic can be harmonized.
gcc/ChangeLog:
* ira-build.cc (setup_pseudos_has_s
This patch relax the subreg track capability to all subreg registers.
gcc/ChangeLog:
* ira-build.cc (get_reg_unit_size): New.
(has_same_nregs): New.
(ira_set_allocno_class): Adjust.
---
gcc/ira-build.cc | 41 -
1 file changed, 36 i
This patch supports tracking subreg liveness. It first extends
ira_object_t objects[2] to std::vector objects,
which can hold more than one object, and is used to collect all
access via subreg in program and the partial_in and partial_out
of the basic block live in/out.
Then there is a modificatio
This patch switches the live_reg data in lra to live_subreg data,
and the situation will be more complicated than in ira because
this part of the data is modified in lra also and the live_subreg
data will be recalculated.
gcc/ChangeLog:
* lra-coalesce.cc (update_live_info):
Adjust
These patches found a new bug and I resend a v3 version, I'm sorry about
this.
V3: https://gcc.gnu.org/pipermail/gcc-patches/2023-November/636178.html
On 2023/11/12 17:58, Lehua Ding wrote:
Hi,
These patchs try to support subreg coalesce feature in
register allocation passes (ira an
This patch changes the previous way of creating a copy between allocnos to
objects.
gcc/ChangeLog:
* ira-build.cc (find_allocno_copy): Removed.
(find_object): New.
(ira_create_copy): Adjust.
(add_allocno_copy_to_list): Adjust.
(swap_allocno_copy_ends_if_ne
+need_track_subreg (int regno, machine_mode mode);
+extern void
+remove_subreg_range (basic_block_subreg_live_info *bb_info, unsigned int regno,
+machine_mode mode, const subreg_range &range);
+extern bool
+remove_subreg_range (basic_block_subreg_live_info *bb_info, df_ref
This patch switch the use of live_reg data to live_subreg data.
gcc/ChangeLog:
* ira-build.cc (create_bb_allocnos): Switch.
(create_loop_allocnos): Ditto.
* ira-color.cc (ira_loop_edge_freq): Ditto.
* ira-emit.cc (generate_edge_moves): Ditto.
(add_ranges_an
5.d
mov z28.d, z6.d
mov z29.d, z7.d
cmp w1, 0
...
```
After these patchs:
```
bar:
ld4d{z28.d - z31.d}, p0/z, [x0]
cmp w1, 0
...
```
Lehua Ding (7):
df: Add DF_LIVE_SUBREG problem
ira: Switch to live_subreg data
ira:
Hi Vladimir,
On 2023/11/10 4:24, Vladimir Makarov wrote:
On 11/7/23 22:47, Lehua Ding wrote:
Lehua Ding (7):
ira: Refactor the handling of register conflicts to make it more
general
ira: Add live_subreg problem and apply to ira pass
ira: Support subreg live range track
ira
Hi Dimitar,
I solved the problem you reported in V2 patch
(https://gcc.gnu.org/pipermail/gcc-patches/2023-November/636166.html),
is it possible for you to help confirm this? Thank you very much.
On 2023/11/9 0:56, Dimitar Dimitrov wrote:
On Wed, Nov 08, 2023 at 11:47:33AM +0800, Lehua Ding
This patch switches the live_reg data in lra to live_subreg data,
and the situation will be more complicated than in ira because
this part of the data is modified in lra also and the live_subreg
data will be recalculated.
gcc/ChangeLog:
* lra-coalesce.cc (update_live_info):
Adjust
+need_track_subreg (int regno, machine_mode mode);
+extern void
+remove_subreg_range (basic_block_subreg_live_info *bb_info, unsigned int regno,
+machine_mode mode, const subreg_range &range);
+extern bool
+remove_subreg_range (basic_block_subreg_live_info *bb_info, df_ref
This patch relax the subreg track capability to all subreg registers.
gcc/ChangeLog:
* ira-build.cc (get_reg_unit_size): New.
(has_same_nregs): New.
(ira_set_allocno_class): Adjust.
---
gcc/ira-build.cc | 41 -
1 file changed, 36 i
This patch supports tracking the liveness of a subreg in a lra pass, with the
goal of getting it to agree with ira's register allocation scheme. There is some
duplication, maybe in the future this part of the code logic can be harmonized.
gcc/ChangeLog:
* ira-build.cc (setup_pseudos_has_s
9.d, z7.d
cmp w1, 0
...
```
After these patchs:
```
bar:
ld4d{z28.d - z31.d}, p0/z, [x0]
cmp w1, 0
...
```
Lehua Ding (7):
df: Add DF_LIVE_SUBREG problem
ira: Switch to live_subreg data
ira: Support subreg live range track
ira: Support s
This patch changes the previous way of creating a copy between allocnos to
objects.
gcc/ChangeLog:
* ira-build.cc (find_allocno_copy): Removed.
(find_object): New.
(ira_create_copy): Adjust.
(add_allocno_copy_to_list): Adjust.
(swap_allocno_copy_ends_if_ne
This patch supports tracking subreg liveness. It first extends
ira_object_t objects[2] to std::vector objects,
which can hold more than one object, and is used to collect all
access via subreg in program and the partial_in and partial_out
of the basic block live in/out.
Then there is a modificatio
This patch switch the use of live_reg data to live_subreg data.
gcc/ChangeLog:
* ira-build.cc (create_bb_allocnos): Switch.
(create_loop_allocnos): Ditto.
* ira-color.cc (ira_loop_edge_freq): Ditto.
* ira-emit.cc (generate_edge_moves): Ditto.
(add_ranges_an
Hi Dimitar,
On 2023/11/11 0:00, Dimitar Dimitrov wrote:
On Fri, Nov 10, 2023 at 04:53:57PM +0800, Lehua Ding wrote:
The divide by zero error above is interesting. I'm not sure why
ira_reg_class_max_nregs[] yields 0 for the pseudo register 168 in
the following rtx:
(debug_insn 168 167 1
On 2023/11/10 18:16, Richard Sandiford wrote:
Lehua Ding writes:
Hi Richard,
On 2023/11/8 17:40, Richard Sandiford wrote:
Tracking subreg liveness will sometimes expose dead code that
wasn't obvious without it. PR89606 has an example of this.
There the dead code was introduced by init
Hi Jeff,
On 2023/11/9 3:13, Jeff Law wrote:
The other thing to ponder. Jivan and I have been banging on Joern's
sub-object tracking bits for a totally different problem in the RISC-V
space. But there may be some overlap.
Essentially Joern's code tracks liveness for a few chunks in registers
On 2023/11/8 11:55, juzhe.zh...@rivai.ai wrote:
Thanks Lehua.
Appreciate for supporting subreg liveness tracking with tons of work.
A nit comments, I think you should mention these following PRs:
106694
89967
106146
99161
No need send V2 now. You can send V2 after Richard and Vlad reviewed
Hi Richard,
On 2023/11/8 17:40, Richard Sandiford wrote:
Tracking subreg liveness will sometimes expose dead code that
wasn't obvious without it. PR89606 has an example of this.
There the dead code was introduced by init-regs, and there's a
debate about (a) whether init-regs should still be run
The divide by zero error above is interesting. I'm not sure why
ira_reg_class_max_nregs[] yields 0 for the pseudo register 168 in the
following rtx:
(debug_insn 168 167 169 19 (var_location:SI encoding (reg/v:SI 168 [
encoding ])) -1
(nil))
I just cross compiled an arm-none-eabi compile
Hi Dimitar,
Thanks for the tests.
This patch set breaks the build for at least three embedded targets. See
below.
For avr the GCC build fails with:
/mnt/nvme/dinux/local-workspace/gcc/gcc/ira-lives.cc:149:39: error: call of overloaded
‘set_subreg_conflict_hard_regs(ira_allocno*&, int&)’ is am
Hi Kito,
On 2023/11/9 17:21, Kito Cheng wrote:
Should we need a zero-ext version as well?
It's not needed at the moment, since the sign_extend is currently used
for both int32_t and uint32_t. I can't find a case where zero_extend
would occur.
--
Best,
Lehua (RiVAI)
lehua.d...@rivai.ai
Committed, thanks Juzhe.
On 2023/11/8 21:29, juzhe.zhong wrote:
lgtm
Replied Message
FromLehua Ding <mailto:lehua.d...@rivai.ai>
Date11/08/2023 21:27
To gcc-patches@gcc.gnu.org
<mailto:gcc-patches@gcc.gnu.org>
Cc juzhe.zh...@rivai.ai
<mailto:juzhe
Hi,
This patch try to combine bellow two insns and then further remove
unnecessary sign_extend operations. This optimization is borrowed
from LLVM (https://godbolt.org/z/4f6v56xej):
(set (reg:DI 134 [ _1 ])
(unspec:DI [
(const_int 19 [0x13])
(const_int 8 [0x8
Hi Richard,
Thanks for taking the time to review the code.
On 2023/11/8 15:57, Richard Biener wrote:
On Wed, Nov 8, 2023 at 4:48 AM Lehua Ding wrote:
This patch does not make any functional changes. It mainly refactor two parts:
1. The ira_allocno's objects field is expanded to an sca
This patch change the use of old live data to the new live_subreg data.
gcc/ChangeLog:
* lra-coalesce.cc (update_live_info): Update.
(lra_coalesce): Update.
* lra-constraints.cc (update_ebb_live_info): Update.
(get_live_on_other_edges): Update.
(inherit_in_
This patch change the copy between allocno and allocno to the copy between
object and object, that is, allow partial copy between pseudo registers.
gcc/ChangeLog:
* ira-build.cc (find_allocno_copy): Removed.
(ira_create_object): Adjust.
(find_object): New.
(ira_cre
This patch extends the reg live range in ira to track the lifecycle
of subreg, thus enabling more granular tracking of the live range and
conflict of a pseudo subreg part. This patch will divide allocno into
two categories: one has single object, and the other is the case where
it contains subreg o
This patch implements tracking of the live range of subregs and synchronously
modifies conflict detection.
gcc/ChangeLog:
* ira-build.cc (print_copy): Adjust print.
(setup_pseudos_has_subreg_object): New.
(ira_build): collect subreg object allocno.
* lra-assigns.cc
This patch completely relax to track all eligible subregs.
gcc/ChangeLog:
* ira-build.cc (get_reg_unit_size): New.
(has_same_nregs): New.
(ira_set_allocno_class): Relax.
---
gcc/ira-build.cc | 41 -
1 file changed, 36 insertions(+)
This patch adds a live_subreg problem to extend the original live_reg to
track the lifecycle of subreg. At the same time, this old live data is
replaced by the new live data in ira pass.
gcc/ChangeLog:
* Makefile.in: Add subreg-live-range.o
* df-problems.cc (struct df_live_subreg_
This patch does not make any functional changes. It mainly refactor two parts:
1. The ira_allocno's objects field is expanded to an scalable array, and
multi-word
pseduo registers are split and tracked only when necessary.
2. Since the objects array has been expanded, there will be more subreg
9.d, z7.d
cmp w1, 0
...
```
After these patchs:
```
bar:
ld4d{z28.d - z31.d}, p0/z, [x0]
cmp w1, 0
...
```
Lehua Ding (7):
ira: Refactor the handling of register conflicts to make it more
general
ira: Add live_subreg problem and apply to
Hi Robin,
On 2023/11/7 15:57, Robin Dapp wrote:
Thanks, what I was slightly concerned about is that we now have
the implicit assumption that the initial value is 0. I mean
that's what the vectorizer does for reductions but theoretically,
wouldn't we also combine other values into 0 now?
Sorry
Committed, thanks Juzhe.
On 2023/11/7 15:51, juzhe.zh...@rivai.ai wrote:
LGTM. Thanks for fixing it.
juzhe.zh...@rivai.ai
*From:* Lehua Ding <mailto:lehua.d...@rivai.ai>
*Date:* 2023-11-07 15:49
*To
Hi,
This patch fixed the fellowing failed testcases on the trunk:
FAIL: gcc.target/riscv/rvv/autovec/cond/cond_widen_reduc-2.c
scan-assembler-times \\tvfwredusum\\.vs\\tv[0-9]+,v[0-9]+,v[0-9]+,v0\\.t 2
...
FAIL: gcc.target/riscv/rvv/autovec/cond/cond_widen_reduc-2.c
scan-assembler-times \\tvwred
Hi Andrew,
Yes and maybe use tree for the type of op_list instead of auto.
I suspect this code was originally written before GCC was written in C++11.
Maybe if this code is being compiled with C++20 we could do something like:
#include
template< std::same_as... op_types>
To get a decent error
Hi Andrew,
On 2023/10/31 14:48, Andrew Pinski wrote:
+inline
+gimple_match_op::gimple_match_op (const gimple_match_cond &cond_in,
+ code_helper code_in, tree type_in,
+ tree op0, tree op1, tree op2, tree op3,
+
Committed, thanks Jeff.
On 2023/9/28 6:24, Jeff Law wrote:
On 9/20/23 07:09, Lehua Ding wrote:
This patch adds combine cond_len_op and vec_cond to cond_len_op like
cond_op.
gcc/ChangeLog:
* gimple-match.h (gimple_match_op::gimple_match_op):
Add interfaces for more arguments
Committed, thanks Jeff.
On 2023/10/17 11:19, Lehua Ding wrote:
Hi Jeff,
Can you replace riscv_vector with riscv_v? That way this will still
work after Joern commits his change to standardize on the riscv_v
target selector.
OK with that change, no need to wait for a review on V2, just go
Committed, thanks Juzhe.
On 2023/10/31 11:43, juzhe.zh...@rivai.ai wrote:
LGTM.
juzhe.zh...@rivai.ai
*From:* Lehua Ding <mailto:lehua.d...@rivai.ai>
*Date:* 2023-10-31 11:39
*To:* gcc-patches <m
Hi,
This patch let the INT64 to FP16 convert split to two small converts
(INT64 -> FP32 and FP32 -> FP16) when expanding instead of dealy the
split to split1 pass. This change could make it possible to combine
the FP32 to FP16 and vcond patterns and so we don't need to add an
combine pattern for I
Hi Richard,
On 2023/10/20 16:28, Richard Biener wrote:
On Fri, 20 Oct 2023, Lehua Ding wrote:
Hi Richard,
I recompile the testcase with the fixup patch and still get the same ICE.
The following fixes it.
Using this patch did fix it, thank you very much.
From
Hi Richard,
I recompile the testcase with the fixup patch and still get the same ICE.
On 2023/10/20 15:37, Richard Biener wrote:
I went a little bit too simple with implementing SLP gather support
for emulated and builtin based gathers. The following fixes the
conflict that appears when runnin
Committed after the commited of the vsetvl pass refactor patch, thanks
Robin.
On 2023/10/19 16:43, Robin Dapp wrote:
Hi Juzhe,
as discussed off-list this approach generally makes sense to me so
the patch LGTM once the vsetvl rework is upstream and settled.
Independently, we still need to unde
v-gnu-toolchain · GitHub
<https://github.com/patrick-rivos/riscv-gnu-toolchain/issues>
juzhe.zh...@rivai.ai
*From:* Lehua Ding <mailto:lehua.d...@rivai.ai>
*Date:* 2023-10-19 16:33
*To:* gcc-
Hi Richard,
I'm hitting a couple of testcase ICEs for RISC-V while testing with the
latest trunk code, it looks like these two patches are causing it, can
you help me look at it? ICE log like bellow:
➜ vsetvl git:(tintin-dev)
~/open-source/riscv-gnu-toolchain-golden/build/dev-rv64gcv_zfh-lp
ssues · patrick-rivos/riscv-gnu-toolchain · GitHub
<https://github.com/patrick-rivos/riscv-gnu-toolchain/issues>
juzhe.zh...@rivai.ai
*From:* Lehua Ding <mailto:lehua.d...@rivai.ai>
*Date:* 2023-10-19
Okay, thanks anyway.
On 2023/10/19 16:38, Robin Dapp wrote:
Hi Lehua,
thanks for the extensive rework. I'm going to let Juzhe handle the review
since it's his pass and he knows it best. Delegated it to him in patchwork.
Regards
Robin
--
Best,
Lehua (RiVAI)
lehua.d...@rivai.ai
vli 15
FAIL: gcc.target/riscv/rvv/vsetvl/vlmax_single_block-18.c -O3 -g
scan-assembler-times vsetvli 3
FAIL: gcc.target/riscv/rvv/vsetvl/vlmax_single_block-19.c -O3 -g
scan-assembler-times vsetvli 15
FAIL: gcc.target/riscv/rvv/vsetvl/vlmax_single_block-9.c -O3 -g
scan-assembler-times vsetvli
gcc/ChangeLog:
* config/riscv/riscv-vsetvl.def (DEF_INCOMPATIBLE_COND): Removed.
(DEF_SEW_LMUL_RULE): New.
(DEF_SEW_LMUL_FUSE_RULE): Removed.
(DEF_POLICY_RULE): New.
(DEF_UNAVAILABLE_COND): Removed.
(DEF_AVL_RULE): New.
(sew_lmul): New.
PR target/111037
PR target/111234
PR target/111725
gcc/testsuite/ChangeLog:
* gcc.target/riscv/rvv/base/scalar_move-1.c: Adjust.
* gcc.target/riscv/rvv/vsetvl/avl_single-23.c: Adjust.
* gcc.target/riscv/rvv/vsetvl/avl_single-46.c: Adjust.
*
gcc/ChangeLog:
* config/riscv/riscv-vsetvl.cc (pre_vsetvl::compute_avl_def_data): New.
(pre_vsetvl::compute_vsetvl_def_data): New.
(pre_vsetvl::compute_lcm_local_properties): New.
---
gcc/config/riscv/riscv-vsetvl.cc | 395 +++
1 file changed,
gcc/ChangeLog:
* config/riscv/riscv-vsetvl.cc (pre_vsetvl::earliest_fuse_vsetvl_info):
New.
(pre_vsetvl::pre_global_vsetvl_info): New.
(pass_vsetvl::prune_expressions): Removed.
(pass_vsetvl::compute_local_properties): Removed.
(pass_vsetvl::earliest_fusion
gcc/ChangeLog:
* config/riscv/riscv-vsetvl.cc (debug): Removed.
(bitmap_union_of_preds_with_entry): New.
(compute_reaching_defintion): New.
(vlmax_avl_p): New.
(enum vsetvl_type): Moved.
(enum emit_type): Moved.
(vlmul_to_str): Moved.
gcc/ChangeLog:
* config/riscv/riscv-vsetvl.cc (pre_vsetvl::emit_vsetvl): New.
(pre_vsetvl::cleaup): New.
(pre_vsetvl::remove_avl_operand): New.
(pre_vsetvl::remove_unused_dest_operand): New.
(pass_vsetvl::get_vsetvl_at_end): Removed.
(local_avl_compa
gcc/ChangeLog:
* config/riscv/riscv-vsetvl.cc (pre_vsetvl::fuse_local_vsetvl_info):
New.
(pass_vsetvl::compute_local_backward_infos): Removed.
(pass_vsetvl::need_vsetvl): Removed.
(pass_vsetvl::transfer_before): Removed.
(pass_vsetvl::transfer_after): Remov
gcc/ChangeLog:
* config/riscv/riscv-vsetvl.cc
(vector_infos_manager::vector_infos_manager): Removed.
(vector_infos_manager::create_expr): Removed.
(class pre_vsetvl): New class.
(vector_infos_manager::get_expr_id): Removed.
(vector_infos_manager::all_same_r
gcc/ChangeLog:
* config/riscv/riscv-vsetvl.cc (avl_info::avl_info): Removed.
(avl_info::single_source_equal_p): Removed.
(avl_info::multiple_source_equal_p): Removed.
(avl_info::operator=): Removed.
(avl_info::operator==): Removed.
(avl_info::operato
gcc/ChangeLog:
* config/riscv/riscv-vsetvl.cc (pass_vsetvl::get_vector_info): Removed.
(pass_vsetvl::get_block_info): Removed.
(pass_vsetvl::update_vector_info): Removed.
(pass_vsetvl::update_block_info): Removed.
(pass_vsetvl::simple_vsetvl): Removed.
1 - 100 of 355 matches
Mail list logo