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).
IIRC there was general consensus on rewriting the lowest level
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
