On Thu, Jul 27, 2023 at 10:43:00 PM Jeff Law <jeffreya...@gmail.com> wrote: > > > >On 7/27/23 02:43, Xiao Zeng wrote: > >> >> 2. According to your opinions, I have modified the code, but out of caution >> for upstream, I conducted a complete regression tests on patch V2, which took >> some time. I was unable to reply to emails and upload patch V2 in a timely >> manner. >Sorry to have wasted your time
It's okay I am very willing to accept opinions from the gcc community. >-- zicond/xventanacondops has lingered >for quite a while and I had a bit of free time yesterday. I felt it was >most useful to try and move this stuff forward. > > > >> >> 3 After you and other maintainers made minor modifications to my patch[1/5] >> and patch[2/5], it has been merged into the master, so I will no longer >> upload patch V2. >Agreed. > >> >> 4 patch[1/5] and patch[2/5], which have been merged into the master, have >> only >> completed basic support for Zicond, and further optimization work needs to be >> completed. These further optimization reactions are reflected in my >> patch[3/5] >> patch[4/5] and patch[5/5]. >Agreed. > >> >> 5 As you mentioned in your previous email >> https://gcc.gnu.org/pipermail/gcc-patches/2023-July/625427.html >> "eswincomputing and ventana can both reduce our divergence from the trunk >> and work together on the rest of the bits...". I will reorganize patch[3/5] >> patch[4/5] >> and patch[5/5], provide more detailed explanations, and submit them as an >> alternative >> solution for further optimization of Zicond. >> >> Does that work for you? >I'm going to look at 3/5 today pretty closely. Exposing zicond to >mov<node>cc is something we had implemented inside Ventana and I want to >compare/contrast your work with ours. What a coincidence! > >What I like about yours is it keeps all the logic in riscv.cc rather >than scattering it across riscv.cc and riscv.md. Yes, when I use enough test cases, I cannot find a concise way to optimize all test cases. When I enumerated all possible cases in the mov<mode>cc function of the RISC-V backend, I found a method that satisfied me, which is the method in patch [3/5]. >What I like about the >internal Ventana bits is its ability to support arbitrary comparisons by >utilizing sCC if the original is not an eq/ne comparison. > If it's just for the Zicond instruction set, is it necessary to make judgments outside of eq/ne? After all, it does not support comparison actions other than eq/ne. Of course, it is also possible to use a special technique to use Zicond in non eq/ne comparisons. >Ideally we'll be able to get the best of both. Of course, it is best to unify all situations in one framework. > >Jeff Now that the code on the master has preliminary support for Zicond, I will still submit the optimization patches for Zicond to the community for the convenience of finding the ideal method. Thanks Xiao Zeng
