On Thu 8. Jun 2023 at 16:17, Jeff Law <jeffreya...@gmail.com> wrote: > > > On 6/8/23 04:22, Kito Cheng wrote: > > > > > > > Oh, okay I got the awkness point...I am ok with that on gcc land, but I > > would like binutils support that first, or remove the extension from the > > mcpu for temporary before binutils support, otherwise it just a broken > > support for that CPU on trunk gcc. > I pushed the binutils bits into the repo a couple months ago: > > > commit 1656d3f8ef56a16745689c03269412988ebcaa54 > > Author: Philipp Tomsich <philipp.toms...@vrull.eu> > > Date: Wed Apr 26 14:09:34 2023 -0600 > > > > RISC-V: Support XVentanaCondOps extension > [ ... ] > > I'd very much like to see the condops go into GCC as well, but I've been > hesitant to move it forward myself. We're still waiting on hardware and > it wasn't clear to me that we really had consensus agreement to move the > bits forward based on an announcement vs waiting on actual hardware > availability (based on the comments from Palmer when I upstreamed the > binutils bits).
Zicondops will go to ratification in the next couple of weeks, and the plan is to revise the patches by then. So I would propose that we move Zicond forward as that happens and (given how small XVentanaCondOps is on-top of Zicond) we pick it up then. > IIRC there was general consensus on rewriting the lowest level That was part of the “moving forward”… this needs a rebase and a major revision. > primitives as if-then-else constructs. Something like this: > > > (define_code_iterator eq_or_ne [eq ne]) > > (define_code_attr n [(eq "") (ne "n")]) > > (define_code_attr rev [(eq "n") (ne "")]) > > > > (define_insn "*vt.maskc<n><mode>" > > [(set (match_operand:X 0 "register_operand" "=r") > > (if_then_else:X > > (eq_or_ne (match_operand:X 1 "register_operand" "r") > > (const_int 0)) > > (const_int 0) > > (match_operand:X 2 "register_operand" "r")))] > > "TARGET_XVENTANACONDOPS" > > "vt.maskc<n>\t%0,%2,%1") > > > > (define_insn "*vt.maskc<n><mode>_reverse" > > [(set (match_operand:X 0 "register_operand" "=r") > > (if_then_else:X > > (eq_or_ne (match_operand:X 1 "register_operand" "r") > > (const_int 0)) > > (match_operand:X 2 "register_operand" "r") > > (const_int 0)))] > > "TARGET_XVENTANACONDOPS" > > "vt.maskc<rev>\t%0,%2,%1") > > That's what we're using internally these days. I would expect zicond to > work in exactly the same manner, but with a different instruction being > emitted. > > We've also got bits here which wire this up in the conditional move > expander and which adjust the ifcvt.cc bits from VRULL to use the > if-then-else form. All this will be useful for zicond as well. > > I don't mind letting zicond go first. It's frozen so it ought to be > non-controversial. We can then upstream the various improvements to > utilize zicond better. That moves things forward in a meaningful manner > and buys time to meet the hardware requirement for xventanacondops which > will be trivial to add if zicond is already supported. > > > > > Jeff >
