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 >