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 -- 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 I like about yours is it keeps all the logic in riscv.cc rather
than scattering it across riscv.cc and riscv.md. 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.
Ideally we'll be able to get the best of both.
Jeff
