Re: Re: [PATCH] vect: Check that vector factor is a compile-time constant

["juzhe.zhong@rivai.ai" <juzhe.zhong@rivai.ai>]

[-- Attachment #1: Type: text/plain, Size: 2552 bytes --]

>> I would object to anyone trying to push forward an autovec implementation into
>> gcc-13.  We're well past that point IMHO, even if the changes only
>> affected the RISC-V backend.

Yes, I am agree with Jeff's opinion. I finished infrastructure (intrinsic and VSETVL PASS) of RVV now.
Now, I am pulling as many resources as possible to do the testing.
From now to April (until GCC 14 is open), I will only keep testing and fix bugs or some codes refine && simplification.
I won't push any more features especially autovec until GCC 14 is open.



juzhe.zhong@rivai.ai
 
From: Jeff Law
Date: 2023-02-23 12:01
To: Michael Collison; juzhe.zhong; gcc-patches
CC: kito.cheng; kito.cheng; richard.sandiford; richard.guenther
Subject: Re: [PATCH] vect: Check that vector factor is a compile-time constant
 
 
On 2/22/23 10:54, Michael Collison wrote:
> Juzhe,
> 
> I disagree with this comment. There are many stakeholders for 
> autovectorization and waiting until GCC 14 is not a viable solution for 
> us as well as other stakeholders ready to begin work on autovectorization.
> 
> As we discussed I have been moving forward with patches for 
> autovectorization and am preparing to send them to gcc-patches. This 
> assert is preventing code from compiling and needs to be addressed.
> 
> If you have a solution in either the RISCV backend or in this file can 
> you please present it?
I don't necessarily think it means waiting for gcc-14, but it does mean 
waiting for gcc-13 to branch and gcc-14 development to open.  I would 
object to anyone trying to push forward an autovec implementation into 
gcc-13.  We're well past that point IMHO, even if the changes only 
affected the RISC-V backend.
 
Given that it looks like we have two independent implementations we're 
almost certainly going to have to sit down with both, evaluate both from 
a quality of code viewpoint and benchmark them both and ultimately 
choose one implementation or the other, or maybe even some mixing and 
matching.
 
I would strongly suggest that both groups have implementations we can 
start evaluating from a design/implementation standpoint relatively 
soon.  Ideally both groups would actually have branches in the repo that 
are regularly updated with their current implementation.
 
While I have a great interest in seeing an autovec implementation move 
forward as soon as possible after gcc-14 development opens, I have no 
opinions at this point about either of the two existing implementations.
 
Jeff