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

[钟居哲 <juzhe.zhong@rivai.ai>]

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

Thanks. 

I think we still can continue RVV feature reviewing process in github branch
that we have talked about. Such patches that have been reviewed I will still send
them to GCC mail list and not to merge right now, we can wait until stage1 is open.

Is it a good idea ? I don't want to make RVV support in GCC stop here since LLVM already has
all RVV support  and GCC is far behind LLVM for a long time in case of RVV.


juzhe.zhong@rivai.ai
 
From: Palmer Dabbelt
Date: 2022-11-29 02:02
To: jeffreyalaw
CC: juzhe.zhong; gcc-patches; Kito Cheng
Subject: Re: [PATCH] RISC-V: Add attributes for VSETVL PASS
On Mon, 28 Nov 2022 08:44:16 PST (-0800), jeffreyalaw@gmail.com wrote:
>
> On 11/28/22 07:14, juzhe.zhong@rivai.ai wrote:
>> From: Ju-Zhe Zhong <juzhe.zhong@rivai.ai>
>>
>> gcc/ChangeLog:
>>
>>          * config/riscv/riscv-protos.h (enum vlmul_type): New enum.
>>          (get_vlmul): New function.
>>          (get_ratio): Ditto.
>>          * config/riscv/riscv-v.cc (struct mode_vtype_group): New struct.
>>          (ENTRY): Adapt for attributes.
>>          (enum vlmul_type): New enum.
>>          (get_vlmul): New function.
>>          (get_ratio): New function.
>>          * config/riscv/riscv-vector-switch.def (ENTRY): Adapt for attributes.
>>          * config/riscv/riscv.cc (ENTRY): Ditto.
>>          * config/riscv/vector.md (false,true): Add attributes.
>
> 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.
 
I'm also on the fence here: the RISC-V V implementation is a huge 
feature so it's a bit awkward to land it this late in the release, but 
on the flip side it's a very important feature.  It's complicated enough 
that whatever our first release is will probably be a mess, so I'd 
prefer to just get that pain out of the way sooner rather than later.  
There's no V hardware availiable now and nothing concretely announced so 
any users are probably going to be pretty advanced, but having at least 
the basics of V in there will allow us to kick the tires on the rest of 
the stack a lot more easily.
 
There's obviously risk to taking something this late in the process.  We 
don't have anything else that triggers the vectorizer, so I think it 
should be seperable enough that risk is manageable.
 
Not sure if Kito wants to chim in, though.
 
> 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.
>
>
> Jeff