On 3/27/23 00:59, juzhe.zh...@rivai.ai wrote:
From: Juzhe-Zhong
PR 108270
Fix bug: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108270.
Consider the following testcase:
void f (void * restrict in, void * restrict out, int l, int n, int m)
{
for (int i = 0; i < l; i++){
for
On 4/5/23 07:53, juzhe.zh...@rivai.ai wrote:
>> So fusion in this context is really about identifying cases where two
configuration settings are equivalent and you "fuse" them together.
Presumably this is only going to be possible when the vector insns are
just doing data movement rather tha
On 4/11/23 17:09, juzhe.zh...@rivai.ai wrote:
I don't want to seperate VSETVL PASS into 2 seperate PASS.
I want make everything cleaner.
Well, two pass vsetvl might actually be cleaner. But as I've noted
before, now is not the time to debate the vsetvl implementation detail.
We've got much
ener; juzhe.zhong
CC: gcc-patches; kito.cheng; palmer
Subject: Re: [PATCH] RISC-V: Fix PR108279
On 4/11/23 02:55, Richard Biener wrote:
>
> Just to throw in a comment here - I think you should present LCM
> with something it can identify as the same for compatible vsetvl and
&g
On 4/11/23 02:55, Richard Biener wrote:
Just to throw in a comment here - I think you should present LCM
with something it can identify as the same for compatible vsetvl and
then it should just work? OTOH if "compatible" is not transitive
that's not possible (but then I can't quickly make u
i
From: Richard Biener
Date: 2023-04-11 19:19
To: juzhe.zh...@rivai.ai
CC: jeffreyalaw; gcc-patches; kito.cheng; palmer
Subject: Re: Re: [PATCH] RISC-V: Fix PR108279
On Tue, Apr 11, 2023 at 11:19 AM juzhe.zh...@rivai.ai
wrote:
>
> No, we can only pass "available" to LCM.
> Passing
ailable for both "vadd" and "vle32",
> so LCM will hoist "vsetvl e8,mf8,TU" outside the LOOP
> and remove all vsetvls inside the loop.
>
>
> juzhe.zh...@rivai.ai
>
>
> From: Richard Biener
> Date: 2023-04-11 16:55
&
available for both "vadd" and "vle32",
so LCM will hoist "vsetvl e8,mf8,TU" outside the LOOP
and remove all vsetvls inside the loop.
juzhe.zh...@rivai.ai
From: Richard Biener
Date: 2023-04-11 16:55
To: juzhe.zhong
CC: Jeff Law; gcc-patches; kito.cheng; palmer
Su
quot; is clearly
> >> short-hand for something (local demand?), whatever it is, make it
> >> clearer in the comment.
>
> Sorry for bad comments in the codes. Currently, I am working on the first
> patch
> of auto-vectorization. After I sent the first patch of auto-ve
bad comments in the codes. Currently, I am working on the first patch
of auto-vectorization. After I sent the first patch of auto-vectorization for
you to
review. I would like to re-check all the comments and code style of VSETVL PASS.
And refine them.
juzhe.zh...@rivai.ai
From: Jeff Law
Date
On 4/2/23 16:40, juzhe.zh...@rivai.ai wrote:
This point is seletected not because LCM but by Phase 3 (VL/VTYPE demand
info backward fusion and propogation) which
is I introduced into VSETVL PASS to enhance LCM && improve vsetvl
instruction performance.
So fusion in this context is really abou
issue
when I start to implement VSETVL PASS.
I leaved it to be fixed after I finished all target GCC 13 features. And Kito
postpone this patch to be merged after GCC 14 is open.
juzhe.zh...@rivai.ai
From: Jeff Law
Date: 2023-04-03 03:41
To: juzhe.zhong; gcc-patches
CC: kito.cheng; palmer
Subje
On 3/27/23 00:59, juzhe.zh...@rivai.ai wrote:
From: Juzhe-Zhong
PR 108270
Fix bug: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108270.
Consider the following testcase:
void f (void * restrict in, void * restrict out, int l, int n, int m)
{
for (int i = 0; i < l; i++){
for
13 matches
Mail list logo
