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
