https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113495
JuzheZhong changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113495
--- Comment #33 from GCC Commits ---
The master branch has been updated by Pan Li :
https://gcc.gnu.org/g:9dd10de15b183f7b662905e1383fdc3a08755f2e
commit r14-8639-g9dd10de15b183f7b662905e1383fdc3a08755f2e
Author: Juzhe-Zhong
Date: Mon Jan
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113495
--- Comment #32 from GCC Commits ---
The master branch has been updated by Pan Li :
https://gcc.gnu.org/g:3132d2d36b4705bb762e61b1c8ca4da7c78a8321
commit r14-8378-g3132d2d36b4705bb762e61b1c8ca4da7c78a8321
Author: Juzhe-Zhong
Date: Tue Jan
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113495
--- Comment #31 from JuzheZhong ---
machine dep reorg : 403.69 ( 56%) 23.48 ( 93%) 427.17 ( 57%)
5290k ( 0%)
Confirm remove RTL DF checking, LICM is no longer be compile-time hog issue.
VSETVL PASS count 56% compile-time.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113495
--- Comment #30 from JuzheZhong ---
Ok. I believe m_avl_def_in && m_avl_def_out can be removed with a better
algorthm.
Then the memory-hog should be fixed soon.
I am gonna rewrite avl_vl_unmodified_between_p and trigger full coverage
testingl
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113495
--- Comment #29 from Richard Biener ---
(In reply to rguent...@suse.de from comment #26)
> On Fri, 19 Jan 2024, juzhe.zhong at rivai dot ai wrote:
>
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113495
> >
> > --- Comment #22 from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113495
--- Comment #28 from JuzheZhong ---
(In reply to Robin Dapp from comment #27)
> Following up on this:
>
> I'm seeing the same thing Patrick does. We create a lot of large non-sparse
> sbitmaps that amount to around 33G in total.
>
> I did
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113495
--- Comment #27 from Robin Dapp ---
Following up on this:
I'm seeing the same thing Patrick does. We create a lot of large non-sparse
sbitmaps that amount to around 33G in total.
I did local experiments replacing all sbitmaps that are not
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113495
--- Comment #26 from rguenther at suse dot de ---
On Fri, 19 Jan 2024, juzhe.zhong at rivai dot ai wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113495
>
> --- Comment #22 from JuzheZhong ---
> (In reply to Richard Biener from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113495
--- Comment #25 from JuzheZhong ---
RISC-V backend memory-hog issue is fixed.
But compile time hog in LICM still there, so keep this PR open.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113495
--- Comment #24 from GCC Commits ---
The master branch has been updated by Robin Dapp :
https://gcc.gnu.org/g:01260a823073675e13dd1fc85cf2657a5396adf2
commit r14-8282-g01260a823073675e13dd1fc85cf2657a5396adf2
Author: Juzhe-Zhong
Date: Fri
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113495
--- Comment #23 from Kito Cheng ---
> I am considering whether we should disable LICM for RISC-V by default if
> vector is enabled ?
That's will cause regression for other program, also may hurt those program not
vectorized but benefited from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113495
--- Comment #22 from JuzheZhong ---
(In reply to Richard Biener from comment #21)
> I once tried to avoid df_reorganize_refs and/or optimize this with the
> blocks involved but failed.
I am considering whether we should disable LICM for RISC-V
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113495
--- Comment #21 from Richard Biener ---
I once tried to avoid df_reorganize_refs and/or optimize this with the blocks
involved but failed.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113495
Richard Biener changed:
What|Removed |Added
See Also||https://gcc.gnu.org/bugzill
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113495
--- Comment #19 from JuzheZhong ---
(In reply to JuzheZhong from comment #18)
> Hi, Robin.
>
> I have fixed patch for memory-hog:
> https://gcc.gnu.org/pipermail/gcc-patches/2024-January/643418.html
>
> I will commit it after the testing.
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113495
--- Comment #18 from JuzheZhong ---
Hi, Robin.
I have fixed patch for memory-hog:
https://gcc.gnu.org/pipermail/gcc-patches/2024-January/643418.html
I will commit it after the testing.
But compile-time hog still exists which is loop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113495
--- Comment #17 from JuzheZhong ---
Ok. Confirm the original test 33383M -> 4796k now.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113495
--- Comment #16 from JuzheZhong ---
(In reply to Andrew Pinski from comment #15)
> (In reply to JuzheZhong from comment #14)
> > Oh. I known the reason now.
> >
> > The issue is not RISC-V backend VSETVL PASS.
> >
> > It's memory bug of
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113495
--- Comment #15 from Andrew Pinski ---
(In reply to JuzheZhong from comment #14)
> Oh. I known the reason now.
>
> The issue is not RISC-V backend VSETVL PASS.
>
> It's memory bug of rtx_equal_p I think.
It is not rtx_equal_p but rather
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113495
--- Comment #14 from JuzheZhong ---
Oh. I known the reason now.
The issue is not RISC-V backend VSETVL PASS.
It's memory bug of rtx_equal_p I think.
We are calling rtx_equal_p which is very costly.
For example, has_nonvlmax_reg_avl is
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113495
--- Comment #13 from JuzheZhong ---
So I think we should investigate why calling has_nonvlmax_reg_avl cost so much
memory.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113495
--- Comment #12 from JuzheZhong ---
Ok. Here is a simple fix which give some hints:
diff --git a/gcc/config/riscv/riscv-vsetvl.cc
b/gcc/config/riscv/riscv-vsetvl.cc
index 2067073185f..ede818140dc 100644
--- a/gcc/config/riscv/riscv-vsetvl.cc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113495
--- Comment #11 from JuzheZhong ---
It should be compute_lcm_local_properties. The memory usage reduce 50% after I
remove this function. I am still investigating.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113495
--- Comment #10 from JuzheZhong ---
No, it's not caused here. I removed the whole function compute_avl_def_data.
The memory usage doesn't change.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113495
--- Comment #9 from Andrew Pinski ---
(In reply to Andrew Pinski from comment #8)
> How sparse is this bitmap will be? bitmap instead of sbitmap should be used
> if the bitmap is going to be sparse. sbitmap is a fixed sized based on the
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113495
--- Comment #8 from Andrew Pinski ---
(In reply to Patrick O'Neill from comment #7)
> I believe the memory hog is caused by this:
> https://gcc.gnu.org/git/?p=gcc.git;a=blob;f=gcc/config/riscv/riscv-vsetvl.cc;
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113495
Patrick O'Neill changed:
What|Removed |Added
CC||patrick at rivosinc dot com
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113495
--- Comment #6 from JuzheZhong ---
(In reply to Andrew Pinski from comment #5)
> Note "loop invariant motion" is the RTL based loop invariant motion pass.
So you mean it should be still RISC-V issue, right ?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113495
Andrew Pinski changed:
What|Removed |Added
Component|tree-optimization |rtl-optimization
--- Comment #5 from
30 matches
Mail list logo
