Re: [PATCH] RISC-V: Add attributes for VSETVL PASS
LGTM, and committed to trunk! On Tue, Nov 29, 2022 at 4:54 PM Kito Cheng 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 :)
Re: [PATCH] RISC-V: Add attributes for VSETVL PASS
> >>> 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 :)
Re: [PATCH] RISC-V: Add attributes for VSETVL PASS
On Mon, 28 Nov 2022 20:49:00 PST (-0800), jeffreya...@gmail.com wrote: On 11/28/22 19:56, Palmer Dabbelt wrote: On Mon, 28 Nov 2022 17:46:16 PST (-0800), juzhe.zh...@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.
Re: [PATCH] RISC-V: Add attributes for VSETVL PASS
On 11/28/22 19:56, Palmer Dabbelt wrote: On Mon, 28 Nov 2022 17:46:16 PST (-0800), juzhe.zh...@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
Re: Re: [PATCH] RISC-V: Add attributes for VSETVL PASS
On Mon, 28 Nov 2022 19:07:24 PST (-0800), juzhe.zh...@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.zh...@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.zh...@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.zh...@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 於 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
Re: Re: [PATCH] RISC-V: Add attributes for VSETVL PASS
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.zh...@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.zh...@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.zh...@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 於 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
Re: Re: [PATCH] RISC-V: Add attributes for VSETVL PASS
On Mon, 28 Nov 2022 17:46:16 PST (-0800), juzhe.zh...@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.zh...@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 於 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
Re: Re: [PATCH] RISC-V: Add attributes for VSETVL PASS
Yeah, I personally want to support RVV intrinsics in GCC13. As RVV intrinsic is going to release soon next week. juzhe.zh...@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 於 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
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 於 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 >
Re: [PATCH] RISC-V: Add attributes for VSETVL PASS
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
Re: Re: [PATCH] RISC-V: Add attributes for VSETVL PASS
On Mon, 28 Nov 2022 15:10:15 PST (-0800), juzhe.zh...@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.zh...@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), jeffreya...@gmail.com wrote: On 11/28/22 07:14, juzhe.zh...@rivai.ai wrote: From: Ju-Zhe Zhong 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
Re: Re: [PATCH] RISC-V: Add attributes for VSETVL PASS
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.zh...@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), jeffreya...@gmail.com wrote: > > On 11/28/22 07:14, juzhe.zh...@rivai.ai wrote: >> From: Ju-Zhe Zhong >> >> 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
Re: Re: [PATCH] RISC-V: Add attributes for VSETVL PASS
>> 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.zh...@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.zh...@rivai.ai wrote: > From: Ju-Zhe Zhong > > 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
Re: [PATCH] RISC-V: Add attributes for VSETVL PASS
On Mon, 28 Nov 2022 08:44:16 PST (-0800), jeffreya...@gmail.com wrote: On 11/28/22 07:14, juzhe.zh...@rivai.ai wrote: From: Ju-Zhe Zhong 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
Re: [PATCH] RISC-V: Add attributes for VSETVL PASS
On 11/28/22 07:14, juzhe.zh...@rivai.ai wrote: From: Ju-Zhe Zhong 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
