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