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

[Palmer Dabbelt <palmer@dabbelt.com>]

On Mon, 28 Nov 2022 15:10:15 PST (-0800), juzhe.zhong@rivai.ai wrote:
> 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.

That also works for me.  We can always stack them up on a vendor branch 
for a few months until things re-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.

Yes, please don't stop ;).  It's really important work!

> 
> 
> 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
>