Re: Re: [PATCH] RISC-V: Add attributes for VSETVL PASS

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

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

In case of RVV intrinsic support, there is no changes outside RISC-V backend
since we don't do the autovectorization support for now.

I will postpone autovectorization until GCC14 is open.


juzhe.zhong@rivai.ai
 
From: Palmer Dabbelt
Date: 2022-11-29 10:56
To: juzhe.zhong
CC: Kito Cheng; jeffreyalaw; gcc-patches
Subject: Re: Re: [PATCH] RISC-V: Add attributes for VSETVL PASS
On Mon, 28 Nov 2022 17:46:16 PST (-0800), juzhe.zhong@rivai.ai wrote:
> Yeah, I personally want to support RVV intrinsics in GCC13. 
> As RVV intrinsic is going to release soon next week.
 
OK, that's fine with me -- I was leaning that way, and I think Jeff only 
had a weak opposition.  Are there any more changes required outside the 
RISC-V backend?  Those would be the most controversial and are already 
late, but if it's only backend stuff at this point then I'm OK taking 
the risk for a bit longer.
 
Jeff?
 
> 
> 
> 
> juzhe.zhong@rivai.ai
>  
> From: Kito Cheng
> Date: 2022-11-29 09:38
> To: Jeff Law
> CC: 钟居哲; gcc-patches; palmer
> Subject: Re: [PATCH] RISC-V: Add attributes for VSETVL PASS
> Actually, I am strongly support those stuff keep merge to trunk until February, my goal is intrinsic support for vector, but not including any vectorization like SLP or Loop vectorization, the most critical part is the vsetvli which is the mode switching, and its almost done.
> 
> Those part is kind of infrastructure for future development (vectorization), so I want intrinsic support could merge at GCC 13.
> 
> 
> and we've included few intrinsic support now, stop there is kind of awkward.
> 
> Jeff Law via Gcc-patches <gcc-patches@gcc.gnu.org> 於 2022年11月29日 週二 07:54 寫道：
> 
> 
> On 11/28/22 15:52, 钟居哲 wrote:
>>  >> I'm tempted to push this into the next stage1 given its arrival after
>>>>stage1 close, but if the wider RISC-V maintainers want to see it move
>>>>forward, I don't object strongly.
>> 
>> Ok, let's save these patches and merge them when GCC14 stage1 is open.
>> Would you mind telling me when will stage 1 be open?
> Typically it's April.  As was noted elsewhere, feel free to keep 
> submitting patches in this space and you can certainly create a branch 
> where y'all can put patches to make it easier to collaborate and 
> ultimately merge with the trunk once stage1 is open again.
> 
>> 
>>  >> I'm curious about the model you're using.  Is it going to be something
>>>>similar to mode switching?  That's the first mental model that comes to
>>>>mind.  Essentially we determine the VL needed for every chunk of code,
>>>>then we do an LCM like algorithm to find the optimal placement points
>>>>for VL sets to minimize the number of VL sets across all the paths
>>>>through the CFG.  Never in a million years would I have expected we'd be
>>>>considering reusing that code.
>> 
>> Yes, I implemented VSETVL PASS with LCM algorithm and RTL_SSA framework.
> Yea,  layering on top of RTL-SSA is probably better than the existing 
> mode-switching which is LCM without SSA.
> 
>> Actually, me && kito have spent a month on VSETVL PASS and we have
>> made a progress. We have tested it with a lot of testcases, turns out 
>> our implementation
>> of VSETVL PASS in GCC has much better codegen than the VSETVL implemented
>> in LLVM side in many different situations because of LCM. I am working 
>> on cleaning up the codes
>> and hopefully you will see it soon in the next patch.
> Good to hear.  I argued pretty loudly in the late 90s that LCM was the 
> right framework for this problem.  We didn't have rtl-ssa, but we did 
> have a pure RTL LCM module that Joern and Andrew were able to re-use to 
> implement sh's mode switching.
> 
> I just never thought we'd see another processor where it'd be useful.
> 
> Jeff