Re: [PATCH 0/5] Recognize Zicond extension

[Jeff Law <jeffreyalaw@gmail.com>]

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