Well, I'm mainly considering that we have added some vset related lines, but they haven't played a new role for the time being. If it's for future modifications, it does make sense.
> This is reducing code size by over 2 kib of code, or several hundreds of instructions. The reduction in code size seems to be due to switching to using j labels, doesn't seem to be about vset, but another issue. j labels are indeed better. I will make similar modifications. Rémi Denis-Courmont <r...@remlab.net> 于2024年5月26日周日 02:29写道： > Le lauantaina 25. toukokuuta 2024, 21.16.22 EEST flow gg a écrit : > > Would it be better to replace the two vsetvlstatic8 and vsetvlstatic16 > with > > two vsetvl? > > The other option is to hard-code the most pessimistic multiplier. That > would > be easier to read and save two instructions in the head, it would most > likely > end up slower overall, due to increased latency from the vector unit in > the > main loop. > > On the other hand, with vsetvl, we have the option to adjust the > multiplier at > run-time depending on hardware vector size. That will not be possible with > vsetvli unless we patch the code live (yikes). > > > This would require the previous patch and this one to work > > together, > > Yes, patch order matters. > > > increasing the number of lines of code > > This is reducing code size by over 2 kib of code, or several hundreds of > instructions. > > > Additionally, I have a question about patch 4 'save one R-V GPR' and > patch > > 5. Should they be submitted as a single patch? Because patch 4 looks > > similar to what I initially submitted, and you suggested changing it to > > save lines of code. If it is only for patch 5, shouldn't they be combined > > together? > > I think people here like to have as small and many patches as possible, as > is > generally considered the right way to use Git. Since patch 4 is a very > minor > but still independent (from patch 5) improvement, it should be separate, > as > far as I understand FFmpeg's practices. > > -- > レミ・デニ-クールモン > http://www.remlab.net/ > > > > _______________________________________________ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > https://ffmpeg.org/mailman/listinfo/ffmpeg-devel > > To unsubscribe, visit link above, or email > ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe". > _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
