diff mbox series

RISC-V: Add attributes for VSETVL PASS

Message ID 20221128141406.242953-1-juzhe.zhong@rivai.ai
State Unresolved
Headers
Series RISC-V: Add attributes for VSETVL PASS |

Checks

Context Check Description
snail/gcc-patch-check warning Git am fail log

Commit Message

juzhe.zhong@rivai.ai Nov. 28, 2022, 2:14 p.m. UTC 
  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.

---
 gcc/config/riscv/riscv-protos.h          |  13 ++
 gcc/config/riscv/riscv-v.cc              |  41 +++++
 gcc/config/riscv/riscv-vector-switch.def |  97 ++++++------
 gcc/config/riscv/riscv.cc                |   2 +-
 gcc/config/riscv/vector.md               | 185 +++++++++++++++++++++++
 5 files changed, 290 insertions(+), 48 deletions(-)

Comments

Jeff Law Nov. 28, 2022, 4:44 p.m. UTC | #1 
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 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
Palmer Dabbelt Nov. 28, 2022, 6:02 p.m. UTC | #2 
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
juzhe.zhong@rivai.ai Nov. 28, 2022, 10:52 p.m. UTC | #3 
>> 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?

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

Thanks



juzhe.zhong@rivai.ai
 
From: Jeff Law
Date: 2022-11-29 00:44
To: juzhe.zhong; gcc-patches
CC: kito.cheng; palmer
Subject: Re: [PATCH] RISC-V: Add attributes for VSETVL PASS
 
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 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
juzhe.zhong@rivai.ai Nov. 28, 2022, 11:10 p.m. UTC | #4 
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
Palmer Dabbelt Nov. 28, 2022, 11:14 p.m. UTC | #5 
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
>
Jeff Law Nov. 28, 2022, 11:54 p.m. UTC | #6 
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
Kito Cheng Nov. 29, 2022, 1:38 a.m. UTC | #7 
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
>
juzhe.zhong@rivai.ai Nov. 29, 2022, 1:46 a.m. UTC | #8 
Yeah, I personally want to support RVV intrinsics in GCC13. 
As RVV intrinsic is going to release soon next week.



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
Palmer Dabbelt Nov. 29, 2022, 2:56 a.m. UTC | #9 
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
juzhe.zhong@rivai.ai Nov. 29, 2022, 3:07 a.m. UTC | #10 
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
Palmer Dabbelt Nov. 29, 2022, 3:11 a.m. UTC | #11 
On Mon, 28 Nov 2022 19:07:24 PST (-0800), juzhe.zhong@rivai.ai wrote:
> In case of RVV intrinsic support, there is no changes outside RISC-V backend
> since we don't do the autovectorization support for now.

OK, I'm fine with that.  Sounds like Kito is too?

> I will postpone autovectorization until GCC14 is open.

We can still review that stuff and keep it on a branch, if that's eaiser 
on your end.

> 
> 
> 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
>
Jeff Law Nov. 29, 2022, 4:49 a.m. UTC | #12 
On 11/28/22 19:56, Palmer Dabbelt wrote:
> 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?
It's not ideal, but I can live with the bits going into gcc-13 as long 
as they don't bleed out of the RISC-V port.

Jeff
Palmer Dabbelt Nov. 29, 2022, 5:21 a.m. UTC | #13 
On Mon, 28 Nov 2022 20:49:00 PST (-0800), jeffreyalaw@gmail.com wrote:
>
>
> On 11/28/22 19:56, Palmer Dabbelt wrote:
>> 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?
> It's not ideal, but I can live with the bits going into gcc-13 as long
> as they don't bleed out of the RISC-V port.

Ya, that's kind of what happens every release though (and not just in 
GCC, it's that way for everything).  Maybe for gcc-14 we can commit to 
taking the stage1/stage3 split seriously in RISC-V land?

It's early enough that nobody should be surprised, and even if we don't 
need to do it as per the GCC rules we're going to go crazy if we keep 
letting things go until the last minute like this.  I think the only 
real fallout we've had so far was the B stuff in binutils, but we've 
been exceedingly close to broken releases way too many times and it's 
going to bite us at some point.
Kito Cheng Nov. 29, 2022, 8:54 a.m. UTC | #14 
> >>> 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?
> > It's not ideal, but I can live with the bits going into gcc-13 as long
> > as they don't bleed out of the RISC-V port.
>
> Ya, that's kind of what happens every release though (and not just in
> GCC, it's that way for everything).  Maybe for gcc-14 we can commit to
> taking the stage1/stage3 split seriously in RISC-V land?
>
> It's early enough that nobody should be surprised, and even if we don't
> need to do it as per the GCC rules we're going to go crazy if we keep
> letting things go until the last minute like this.  I think the only
> real fallout we've had so far was the B stuff in binutils, but we've
> been exceedingly close to broken releases way too many times and it's
> going to bite us at some point.

I hope we can follow GCC development rule in GCC 14 too, we don't have enough
engineer resource and community in RISC-V GNU land before, but now we have
more people join the development work and review work, so I believe that
could be improved next year.



Hi Jeff:

Thanksgiving holiday is over, but I guess it's never too late to say thanks.
Thank you for joining the RISC-V world and helping review lots of patches :)
Kito Cheng Dec. 1, 2022, 4:05 p.m. UTC | #15 
LGTM, and committed to trunk!

On Tue, Nov 29, 2022 at 4:54 PM Kito Cheng <kito.cheng@gmail.com> 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?
> > > It's not ideal, but I can live with the bits going into gcc-13 as long
> > > as they don't bleed out of the RISC-V port.
> >
> > Ya, that's kind of what happens every release though (and not just in
> > GCC, it's that way for everything).  Maybe for gcc-14 we can commit to
> > taking the stage1/stage3 split seriously in RISC-V land?
> >
> > It's early enough that nobody should be surprised, and even if we don't
> > need to do it as per the GCC rules we're going to go crazy if we keep
> > letting things go until the last minute like this.  I think the only
> > real fallout we've had so far was the B stuff in binutils, but we've
> > been exceedingly close to broken releases way too many times and it's
> > going to bite us at some point.
>
> I hope we can follow GCC development rule in GCC 14 too, we don't have enough
> engineer resource and community in RISC-V GNU land before, but now we have
> more people join the development work and review work, so I believe that
> could be improved next year.
>
>
>
> Hi Jeff:
>
> Thanksgiving holiday is over, but I guess it's never too late to say thanks.
> Thank you for joining the RISC-V world and helping review lots of patches :)
diff mbox series

Patch

diff --git a/gcc/config/riscv/riscv-protos.h b/gcc/config/riscv/riscv-protos.h
index 27692ffb210..e17e003f8e2 100644
--- a/gcc/config/riscv/riscv-protos.h
+++ b/gcc/config/riscv/riscv-protos.h
@@ -120,6 +120,17 @@  extern void riscv_run_selftests (void);
 
 namespace riscv_vector {
 #define RVV_VLMAX gen_rtx_REG (Pmode, X0_REGNUM)
+enum vlmul_type
+{
+  LMUL_1 = 0,
+  LMUL_2 = 1,
+  LMUL_4 = 2,
+  LMUL_8 = 3,
+  LMUL_RESERVED = 4,
+  LMUL_F8 = 5,
+  LMUL_F4 = 6,
+  LMUL_F2 = 7,
+};
 /* Routines implemented in riscv-vector-builtins.cc.  */
 extern void init_builtins (void);
 extern const char *mangle_builtin_type (const_tree);
@@ -132,6 +143,8 @@  extern rtx expand_builtin (unsigned int, tree, rtx);
 extern bool const_vec_all_same_in_range_p (rtx, HOST_WIDE_INT, HOST_WIDE_INT);
 extern bool legitimize_move (rtx, rtx, machine_mode);
 extern void emit_pred_op (unsigned, rtx, rtx, machine_mode);
+extern enum vlmul_type get_vlmul (machine_mode);
+extern unsigned int get_ratio (machine_mode);
 enum tail_policy
 {
   TAIL_UNDISTURBED = 0,
diff --git a/gcc/config/riscv/riscv-v.cc b/gcc/config/riscv/riscv-v.cc
index fbd8bbfe254..d54795694f1 100644
--- a/gcc/config/riscv/riscv-v.cc
+++ b/gcc/config/riscv/riscv-v.cc
@@ -214,4 +214,45 @@  legitimize_move (rtx dest, rtx src, machine_mode mask_mode)
   return true;
 }
 
+/* VTYPE information for machine_mode.  */
+struct mode_vtype_group
+{
+  enum vlmul_type vlmul_for_min_vlen32[NUM_MACHINE_MODES];
+  uint8_t ratio_for_min_vlen32[NUM_MACHINE_MODES];
+  enum vlmul_type vlmul_for_min_vlen64[NUM_MACHINE_MODES];
+  uint8_t ratio_for_min_vlen64[NUM_MACHINE_MODES];
+  mode_vtype_group ()
+  {
+#define ENTRY(MODE, REQUIREMENT, VLMUL_FOR_MIN_VLEN32, RATIO_FOR_MIN_VLEN32,   \
+	      VLMUL_FOR_MIN_VLEN64, RATIO_FOR_MIN_VLEN64)                      \
+  vlmul_for_min_vlen32[MODE##mode] = VLMUL_FOR_MIN_VLEN32;                     \
+  ratio_for_min_vlen32[MODE##mode] = RATIO_FOR_MIN_VLEN32;                     \
+  vlmul_for_min_vlen64[MODE##mode] = VLMUL_FOR_MIN_VLEN64;                     \
+  ratio_for_min_vlen64[MODE##mode] = RATIO_FOR_MIN_VLEN64;
+#include "riscv-vector-switch.def"
+  }
+};
+
+static mode_vtype_group mode_vtype_infos;
+
+/* Get vlmul field value by comparing LMUL with BYTES_PER_RISCV_VECTOR.  */
+enum vlmul_type
+get_vlmul (machine_mode mode)
+{
+  if (TARGET_MIN_VLEN == 32)
+    return mode_vtype_infos.vlmul_for_min_vlen32[mode];
+  else
+    return mode_vtype_infos.vlmul_for_min_vlen64[mode];
+}
+
+/* Get ratio according to machine mode.  */
+unsigned int
+get_ratio (machine_mode mode)
+{
+  if (TARGET_MIN_VLEN == 32)
+    return mode_vtype_infos.ratio_for_min_vlen32[mode];
+  else
+    return mode_vtype_infos.ratio_for_min_vlen64[mode];
+}
+
 } // namespace riscv_vector
diff --git a/gcc/config/riscv/riscv-vector-switch.def b/gcc/config/riscv/riscv-vector-switch.def
index ee8ebd5f1cc..a51f45be487 100644
--- a/gcc/config/riscv/riscv-vector-switch.def
+++ b/gcc/config/riscv/riscv-vector-switch.def
@@ -80,7 +80,8 @@  TODO: FP16 vector needs support of 'zvfh', we don't support it yet.  */
 /* Return 'REQUIREMENT' for machine_mode 'MODE'.
    For example: 'MODE' = VNx64BImode needs TARGET_MIN_VLEN > 32.  */
 #ifndef ENTRY
-#define ENTRY(MODE, REQUIREMENT)
+#define ENTRY(MODE, REQUIREMENT, VLMUL_FOR_MIN_VLEN32, RATIO_FOR_MIN_VLEN32,   \
+	      VLMUL_FOR_MIN_VLEN64, RATIO_FOR_MIN_VLEN64)
 #endif
 /* Flag of FP32 vector.  */
 #ifndef TARGET_VECTOR_FP32
@@ -94,66 +95,68 @@  TODO: FP16 vector needs support of 'zvfh', we don't support it yet.  */
 #endif
 
 /* Mask modes. Disable VNx64BImode when TARGET_MIN_VLEN == 32.  */
-ENTRY (VNx64BI, TARGET_MIN_VLEN > 32)
-ENTRY (VNx32BI, true)
-ENTRY (VNx16BI, true)
-ENTRY (VNx8BI, true)
-ENTRY (VNx4BI, true)
-ENTRY (VNx2BI, true)
-ENTRY (VNx1BI, true)
+ENTRY (VNx64BI, TARGET_MIN_VLEN > 32, LMUL_F8, 64, LMUL_RESERVED, 0)
+ENTRY (VNx32BI, true, LMUL_F4, 32, LMUL_RESERVED, 0)
+ENTRY (VNx16BI, true, LMUL_F2, 16, LMUL_RESERVED, 0)
+ENTRY (VNx8BI, true, LMUL_1, 8, LMUL_RESERVED, 0)
+ENTRY (VNx4BI, true, LMUL_2, 4, LMUL_RESERVED, 0)
+ENTRY (VNx2BI, true, LMUL_4, 2, LMUL_RESERVED, 0)
+ENTRY (VNx1BI, true, LMUL_8, 1, LMUL_RESERVED, 0)
 
 /* SEW = 8. Disable VNx64QImode when TARGET_MIN_VLEN == 32.  */
-ENTRY (VNx64QI, TARGET_MIN_VLEN > 32)
-ENTRY (VNx32QI, true)
-ENTRY (VNx16QI, true)
-ENTRY (VNx8QI, true)
-ENTRY (VNx4QI, true)
-ENTRY (VNx2QI, true)
-ENTRY (VNx1QI, true)
+ENTRY (VNx64QI, TARGET_MIN_VLEN > 32, LMUL_8, 1, LMUL_RESERVED, 0)
+ENTRY (VNx32QI, true, LMUL_8, 1, LMUL_4, 2)
+ENTRY (VNx16QI, true, LMUL_4, 2, LMUL_2, 4)
+ENTRY (VNx8QI, true, LMUL_2, 4, LMUL_1, 8)
+ENTRY (VNx4QI, true, LMUL_1, 8, LMUL_F2, 16)
+ENTRY (VNx2QI, true, LMUL_F2, 16, LMUL_F4, 32)
+ENTRY (VNx1QI, true, LMUL_F4, 32, LMUL_F8, 64)
 
 /* SEW = 16. Disable VNx32HImode when TARGET_MIN_VLEN == 32.  */
-ENTRY (VNx32HI, TARGET_MIN_VLEN > 32)
-ENTRY (VNx16HI, true)
-ENTRY (VNx8HI, true)
-ENTRY (VNx4HI, true)
-ENTRY (VNx2HI, true)
-ENTRY (VNx1HI, true)
+ENTRY (VNx32HI, TARGET_MIN_VLEN > 32, LMUL_8, 2, LMUL_RESERVED, 0)
+ENTRY (VNx16HI, true, LMUL_8, 2, LMUL_4, 4)
+ENTRY (VNx8HI, true, LMUL_4, 4, LMUL_2, 8)
+ENTRY (VNx4HI, true, LMUL_2, 8, LMUL_1, 16)
+ENTRY (VNx2HI, true, LMUL_1, 16, LMUL_F2, 32)
+ENTRY (VNx1HI, true, LMUL_F2, 32, LMUL_F4, 64)
 
 /* TODO:Disable all FP16 vector, enable them when 'zvfh' is supported.  */
-ENTRY (VNx32HF, false)
-ENTRY (VNx16HF, false)
-ENTRY (VNx8HF, false)
-ENTRY (VNx4HF, false)
-ENTRY (VNx2HF, false)
-ENTRY (VNx1HF, false)
+ENTRY (VNx32HF, false, LMUL_8, 2, LMUL_RESERVED, 0)
+ENTRY (VNx16HF, false, LMUL_8, 2, LMUL_4, 4)
+ENTRY (VNx8HF, false, LMUL_4, 4, LMUL_2, 8)
+ENTRY (VNx4HF, false, LMUL_2, 8, LMUL_1, 16)
+ENTRY (VNx2HF, false, LMUL_1, 16, LMUL_F2, 32)
+ENTRY (VNx1HF, false, LMUL_F2, 32, LMUL_F4, 64)
 
 /* SEW = 32. Disable VNx16SImode when TARGET_MIN_VLEN == 32.
    For single-precision floating-point, we need TARGET_VECTOR_FP32 ==
    RVV_ENABLE.  */
-ENTRY (VNx16SI, TARGET_MIN_VLEN > 32)
-ENTRY (VNx8SI, true)
-ENTRY (VNx4SI, true)
-ENTRY (VNx2SI, true)
-ENTRY (VNx1SI, true)
-
-ENTRY (VNx16SF, TARGET_VECTOR_FP32 && (TARGET_MIN_VLEN > 32))
-ENTRY (VNx8SF, TARGET_VECTOR_FP32)
-ENTRY (VNx4SF, TARGET_VECTOR_FP32)
-ENTRY (VNx2SF, TARGET_VECTOR_FP32)
-ENTRY (VNx1SF, TARGET_VECTOR_FP32)
+ENTRY (VNx16SI, TARGET_MIN_VLEN > 32, LMUL_8, 4, LMUL_RESERVED, 0)
+ENTRY (VNx8SI, true, LMUL_8, 4, LMUL_4, 8)
+ENTRY (VNx4SI, true, LMUL_4, 8, LMUL_2, 4)
+ENTRY (VNx2SI, true, LMUL_2, 16, LMUL_1, 2)
+ENTRY (VNx1SI, true, LMUL_1, 32, LMUL_F2, 1)
+
+ENTRY (VNx16SF, TARGET_VECTOR_FP32 && (TARGET_MIN_VLEN > 32), LMUL_8, 4,
+       LMUL_RESERVED, 0)
+ENTRY (VNx8SF, TARGET_VECTOR_FP32, LMUL_8, 4, LMUL_4, 8)
+ENTRY (VNx4SF, TARGET_VECTOR_FP32, LMUL_4, 8, LMUL_2, 4)
+ENTRY (VNx2SF, TARGET_VECTOR_FP32, LMUL_2, 16, LMUL_1, 2)
+ENTRY (VNx1SF, TARGET_VECTOR_FP32, LMUL_1, 32, LMUL_F2, 1)
 
 /* SEW = 64. Enable when TARGET_MIN_VLEN > 32.
    For double-precision floating-point, we need TARGET_VECTOR_FP64 ==
    RVV_ENABLE.  */
-ENTRY (VNx8DI, TARGET_MIN_VLEN > 32)
-ENTRY (VNx4DI, TARGET_MIN_VLEN > 32)
-ENTRY (VNx2DI, TARGET_MIN_VLEN > 32)
-ENTRY (VNx1DI, TARGET_MIN_VLEN > 32)
-
-ENTRY (VNx8DF, TARGET_VECTOR_FP64 && (TARGET_MIN_VLEN > 32))
-ENTRY (VNx4DF, TARGET_VECTOR_FP64)
-ENTRY (VNx2DF, TARGET_VECTOR_FP64)
-ENTRY (VNx1DF, TARGET_VECTOR_FP64)
+ENTRY (VNx8DI, TARGET_MIN_VLEN > 32, LMUL_RESERVED, 0, LMUL_8, 8)
+ENTRY (VNx4DI, TARGET_MIN_VLEN > 32, LMUL_RESERVED, 0, LMUL_4, 16)
+ENTRY (VNx2DI, TARGET_MIN_VLEN > 32, LMUL_RESERVED, 0, LMUL_2, 32)
+ENTRY (VNx1DI, TARGET_MIN_VLEN > 32, LMUL_RESERVED, 0, LMUL_1, 64)
+
+ENTRY (VNx8DF, TARGET_VECTOR_FP64 && (TARGET_MIN_VLEN > 32), LMUL_RESERVED, 0,
+       LMUL_8, 8)
+ENTRY (VNx4DF, TARGET_VECTOR_FP64, LMUL_RESERVED, 0, LMUL_4, 16)
+ENTRY (VNx2DF, TARGET_VECTOR_FP64, LMUL_RESERVED, 0, LMUL_2, 32)
+ENTRY (VNx1DF, TARGET_VECTOR_FP64, LMUL_RESERVED, 0, LMUL_1, 64)
 
 #undef TARGET_VECTOR_FP32
 #undef TARGET_VECTOR_FP64
diff --git a/gcc/config/riscv/riscv.cc b/gcc/config/riscv/riscv.cc
index 0267494ae5a..1198a08b13e 100644
--- a/gcc/config/riscv/riscv.cc
+++ b/gcc/config/riscv/riscv.cc
@@ -955,7 +955,7 @@  riscv_valid_lo_sum_p (enum riscv_symbol_type sym_type, machine_mode mode,
 bool
 riscv_v_ext_vector_mode_p (machine_mode mode)
 {
-#define ENTRY(MODE, REQUIREMENT)                                               \
+#define ENTRY(MODE, REQUIREMENT, ...)                                          \
   case MODE##mode:                                                             \
     return REQUIREMENT;
   switch (mode)
diff --git a/gcc/config/riscv/vector.md b/gcc/config/riscv/vector.md
index 0dace449316..3bb87232d3f 100644
--- a/gcc/config/riscv/vector.md
+++ b/gcc/config/riscv/vector.md
@@ -34,6 +34,191 @@ 
   UNSPEC_VPREDICATE
 ])
 
+(define_constants [
+   (INVALID_ATTRIBUTE            255)
+])
+
+;; True if the type is RVV instructions that include VTYPE
+;; global status register in the use op list.
+;; We known VTYPE has 4 fields: SEW, LMUL, TA, MA.
+;; The instruction need any of VTYPE field is set as true
+;; in this attribute.
+(define_attr "has_vtype_op" "false,true"
+  (cond [(eq_attr "type" "vlde,vste,vldm,vstm,vlds,vsts,\
+			  vldux,vldox,vstux,vstox,vldff,\
+			  vialu,viwalu,vext,vicalu,vshift,vnshift,vicmp,\
+			  vimul,vidiv,viwmul,vimuladd,viwmuladd,vimerge,vimov,\
+			  vsalu,vaalu,vsmul,vsshift,vnclip,\
+			  vfalu,vfwalu,vfmul,vfdiv,vfwmul,vfmuladd,vfwmuladd,vfsqrt,vfrecp,\
+			  vfcmp,vfsgnj,vfclass,vfmerge,vfmov,\
+			  vfcvtitof,vfcvtftoi,vfwcvtitof,vfwcvtftoi,\
+			  vfwcvtftof,vfncvtitof,vfncvtftoi,vfncvtftof,\
+			  vired,viwred,vfred,vfredo,vfwred,vfwredo,\
+			  vmalu,vmpop,vmffs,vmsfs,vmiota,vmidx,vimovvx,vimovxv,vfmovvf,vfmovfv,\
+			  vislide,vislide1,vfslide1,vgather,vcompress")
+	 (const_string "true")]
+	(const_string "false")))
+
+;; True if the type is RVV instructions that include VL
+;; global status register in the use op list.
+;; The instruction need vector length to be specified is set
+;; in this attribute.
+(define_attr "has_vl_op" "false,true"
+  (cond [(eq_attr "type" "vlde,vste,vldm,vstm,vlds,vsts,\
+			  vldux,vldox,vstux,vstox,vldff,\
+			  vialu,viwalu,vext,vicalu,vshift,vnshift,vicmp,\
+			  vimul,vidiv,viwmul,vimuladd,viwmuladd,vimerge,vimov,\
+			  vsalu,vaalu,vsmul,vsshift,vnclip,\
+			  vfalu,vfwalu,vfmul,vfdiv,vfwmul,vfmuladd,vfwmuladd,vfsqrt,vfrecp,\
+			  vfcmp,vfsgnj,vfclass,vfmerge,vfmov,\
+			  vfcvtitof,vfcvtftoi,vfwcvtitof,vfwcvtftoi,\
+			  vfwcvtftof,vfncvtitof,vfncvtftoi,vfncvtftof,\
+			  vired,viwred,vfred,vfredo,vfwred,vfwredo,\
+			  vmalu,vmpop,vmffs,vmsfs,vmiota,vmidx,vimovxv,vfmovfv,\
+			  vislide,vislide1,vfslide1,vgather,vcompress")
+	 (const_string "true")]
+	(const_string "false")))
+
+;; The default SEW of RVV instruction. This attribute doesn't mean the instruction
+;; is necessary to require SEW check for example vlm.v which require ratio to
+;; check. However, we need default value of SEW for vsetvl instruction since there
+;; is no field for ratio in the vsetvl instruction encoding.
+(define_attr "sew" ""
+  (cond [(eq_attr "mode" "VNx1QI,VNx2QI,VNx4QI,VNx8QI,VNx16QI,VNx32QI,VNx64QI,\
+			  VNx1BI,VNx2BI,VNx4BI,VNx8BI,VNx16BI,VNx32BI,VNx64BI")
+	 (const_int 8)
+	 (eq_attr "mode" "VNx1HI,VNx2HI,VNx4HI,VNx8HI,VNx16HI,VNx32HI")
+	 (const_int 16)
+	 (eq_attr "mode" "VNx1SI,VNx2SI,VNx4SI,VNx8SI,VNx16SI,\
+			  VNx1SF,VNx2SF,VNx4SF,VNx8SF,VNx16SF")
+	 (const_int 32)
+	 (eq_attr "mode" "VNx1DI,VNx2DI,VNx4DI,VNx8DI,\
+			  VNx1DF,VNx2DF,VNx4DF,VNx8DF")
+	 (const_int 64)]
+	(const_int INVALID_ATTRIBUTE)))
+
+;; Ditto to LMUL.
+(define_attr "vlmul" ""
+  (cond [(eq_attr "mode" "VNx1QI,VNx1BI")
+	   (symbol_ref "riscv_vector::get_vlmul(E_VNx1QImode)")
+	 (eq_attr "mode" "VNx2QI,VNx2BI")
+	   (symbol_ref "riscv_vector::get_vlmul(E_VNx2QImode)")
+	 (eq_attr "mode" "VNx4QI,VNx4BI")
+	   (symbol_ref "riscv_vector::get_vlmul(E_VNx4QImode)")
+	 (eq_attr "mode" "VNx8QI,VNx8BI")
+	   (symbol_ref "riscv_vector::get_vlmul(E_VNx8QImode)")
+	 (eq_attr "mode" "VNx16QI,VNx16BI")
+	   (symbol_ref "riscv_vector::get_vlmul(E_VNx16QImode)")
+	 (eq_attr "mode" "VNx32QI,VNx32BI")
+	   (symbol_ref "riscv_vector::get_vlmul(E_VNx32QImode)")
+	 (eq_attr "mode" "VNx64QI,VNx64BI")
+	   (symbol_ref "riscv_vector::get_vlmul(E_VNx64QImode)")
+	 (eq_attr "mode" "VNx1HI")
+	   (symbol_ref "riscv_vector::get_vlmul(E_VNx1HImode)")
+	 (eq_attr "mode" "VNx2HI")
+	   (symbol_ref "riscv_vector::get_vlmul(E_VNx2HImode)")
+	 (eq_attr "mode" "VNx4HI")
+	   (symbol_ref "riscv_vector::get_vlmul(E_VNx4HImode)")
+	 (eq_attr "mode" "VNx8HI")
+	   (symbol_ref "riscv_vector::get_vlmul(E_VNx8HImode)")
+	 (eq_attr "mode" "VNx16HI")
+	   (symbol_ref "riscv_vector::get_vlmul(E_VNx16HImode)")
+	 (eq_attr "mode" "VNx32HI")
+	   (symbol_ref "riscv_vector::get_vlmul(E_VNx32HImode)")
+	 (eq_attr "mode" "VNx1SI,VNx1SF")
+	   (symbol_ref "riscv_vector::get_vlmul(E_VNx1SImode)")
+	 (eq_attr "mode" "VNx2SI,VNx2SF")
+	   (symbol_ref "riscv_vector::get_vlmul(E_VNx2SImode)")
+	 (eq_attr "mode" "VNx4SI,VNx4SF")
+	   (symbol_ref "riscv_vector::get_vlmul(E_VNx4SImode)")
+	 (eq_attr "mode" "VNx8SI,VNx8SF")
+	   (symbol_ref "riscv_vector::get_vlmul(E_VNx8SImode)")
+	 (eq_attr "mode" "VNx16SI,VNx16SF")
+	   (symbol_ref "riscv_vector::get_vlmul(E_VNx16SImode)")
+	 (eq_attr "mode" "VNx1DI,VNx1DF")
+	   (symbol_ref "riscv_vector::get_vlmul(E_VNx1DImode)")
+	 (eq_attr "mode" "VNx2DI,VNx2DF")
+	   (symbol_ref "riscv_vector::get_vlmul(E_VNx2DImode)")
+	 (eq_attr "mode" "VNx4DI,VNx4DF")
+	   (symbol_ref "riscv_vector::get_vlmul(E_VNx4DImode)")
+	 (eq_attr "mode" "VNx8DI,VNx8DF")
+	   (symbol_ref "riscv_vector::get_vlmul(E_VNx8DImode)")]
+	(const_int INVALID_ATTRIBUTE)))
+
+;; It is valid for instruction that require sew/lmul ratio.
+(define_attr "ratio" ""
+  (cond [(eq_attr "type" "vimov,vfmov")
+	   (const_int INVALID_ATTRIBUTE)
+	 (eq_attr "mode" "VNx1QI,VNx1BI")
+	   (symbol_ref "riscv_vector::get_ratio(E_VNx1QImode)")
+	 (eq_attr "mode" "VNx2QI,VNx2BI")
+	   (symbol_ref "riscv_vector::get_ratio(E_VNx2QImode)")
+	 (eq_attr "mode" "VNx4QI,VNx4BI")
+	   (symbol_ref "riscv_vector::get_ratio(E_VNx4QImode)")
+	 (eq_attr "mode" "VNx8QI,VNx8BI")
+	   (symbol_ref "riscv_vector::get_ratio(E_VNx8QImode)")
+	 (eq_attr "mode" "VNx16QI,VNx16BI")
+	   (symbol_ref "riscv_vector::get_ratio(E_VNx16QImode)")
+	 (eq_attr "mode" "VNx32QI,VNx32BI")
+	   (symbol_ref "riscv_vector::get_ratio(E_VNx32QImode)")
+	 (eq_attr "mode" "VNx64QI,VNx64BI")
+	   (symbol_ref "riscv_vector::get_ratio(E_VNx64QImode)")
+	 (eq_attr "mode" "VNx1HI")
+	   (symbol_ref "riscv_vector::get_ratio(E_VNx1HImode)")
+	 (eq_attr "mode" "VNx2HI")
+	   (symbol_ref "riscv_vector::get_ratio(E_VNx2HImode)")
+	 (eq_attr "mode" "VNx4HI")
+	   (symbol_ref "riscv_vector::get_ratio(E_VNx4HImode)")
+	 (eq_attr "mode" "VNx8HI")
+	   (symbol_ref "riscv_vector::get_ratio(E_VNx8HImode)")
+	 (eq_attr "mode" "VNx16HI")
+	   (symbol_ref "riscv_vector::get_ratio(E_VNx16HImode)")
+	 (eq_attr "mode" "VNx32HI")
+	   (symbol_ref "riscv_vector::get_ratio(E_VNx32HImode)")
+	 (eq_attr "mode" "VNx1SI,VNx1SF")
+	   (symbol_ref "riscv_vector::get_ratio(E_VNx1SImode)")
+	 (eq_attr "mode" "VNx2SI,VNx2SF")
+	   (symbol_ref "riscv_vector::get_ratio(E_VNx2SImode)")
+	 (eq_attr "mode" "VNx4SI,VNx4SF")
+	   (symbol_ref "riscv_vector::get_ratio(E_VNx4SImode)")
+	 (eq_attr "mode" "VNx8SI,VNx8SF")
+	   (symbol_ref "riscv_vector::get_ratio(E_VNx8SImode)")
+	 (eq_attr "mode" "VNx16SI,VNx16SF")
+	   (symbol_ref "riscv_vector::get_ratio(E_VNx16SImode)")
+	 (eq_attr "mode" "VNx1DI,VNx1DF")
+	   (symbol_ref "riscv_vector::get_ratio(E_VNx1DImode)")
+	 (eq_attr "mode" "VNx2DI,VNx2DF")
+	   (symbol_ref "riscv_vector::get_ratio(E_VNx2DImode)")
+	 (eq_attr "mode" "VNx4DI,VNx4DF")
+	   (symbol_ref "riscv_vector::get_ratio(E_VNx4DImode)")
+	 (eq_attr "mode" "VNx8DI,VNx8DF")
+	   (symbol_ref "riscv_vector::get_ratio(E_VNx8DImode)")]
+	(const_int INVALID_ATTRIBUTE)))
+
+;; The index of operand[] to get the merge op.
+(define_attr "merge_op_idx" ""
+	(cond [(eq_attr "type" "vlde,vste,vimov,vfmov,vldm,vstm,vlds,vmalu")
+	 (const_int 2)]
+	(const_int INVALID_ATTRIBUTE)))
+
+;; The index of operand[] to get the avl op.
+(define_attr "vl_op_idx" ""
+	(cond [(eq_attr "type" "vlde,vste,vimov,vfmov,vldm,vstm,vlds,vmalu")
+	 (const_int 4)]
+	(const_int INVALID_ATTRIBUTE)))
+
+;; The index of operand[] to get the tail policy op.
+(define_attr "tail_policy_op_idx" ""
+  (cond [(eq_attr "type" "vlde,vste,vimov,vfmov,vlds")
+	 (const_int 5)]
+	(const_int INVALID_ATTRIBUTE)))
+
+;; The index of operand[] to get the mask policy op.
+(define_attr "mask_policy_op_idx" ""
+  (cond [(eq_attr "type" "vlde,vste,vlds")
+	 (const_int 6)]
+	(const_int INVALID_ATTRIBUTE)))
+
 ;; -----------------------------------------------------------------
 ;; ---- Miscellaneous Operations
 ;; -----------------------------------------------------------------