On Tue, 05 Sep 2023 20:07:16 PDT (-0700), gcc-patches@gcc.gnu.org wrote:
On 9/5/23 20:33, Tsukasa OI wrote:
Internally we have this as:
(TARGET_ZICOND || TARGET_XVENTANACONDOPS)
I don't really care, so I'm happy to go with yours.
Because XVentanaCondOps instructions are only available on 64-bit target
(I wanted to prevent misuses because we don't reject XVentanaCondOps on
RV32), the target expression would be:
(a) (TARGT_ZICOND || (TARGET_XVENTANACONDOPS && TARGET_64BIT))
and I had three options to deal with it.
1. Use the plain expression (a)
2. Name te expression (a)
3. Enable TARGET_XVENTANACONDOPS only on 64-bit target
I think option 2 is the simplest yet understandable.
Sure. It may also give us the option to roll in some of the thead code
at some point. Their conditional move support seems to line up pretty
well with zicond/xventanacondops too, though I haven't looked at it very
deeply yet.
IIUC the T-Head stuff is actually a conditional move, so it's a little
different than the conditional move/zero extensions (which IIUC have
exactly the same semantics, just different encodings). Hopefully the
cmov fits in a bit easier, we shouldn't need to juggle the extra 0
input.
I'm happy to hear that because I had no confidence so whether we can use
#include to share common parts. I haven't tried yet but I believe we
have to #include only common parts (not including dg instructions
containing -march=..._zicond) so I will likely required to modify zicond
tests as well.
You actually don't even have to break out the common parts. The dg-
directives in an included file aren't parsed by the dg framework.
I'll submit PATCH v4 (not committing directly) as changes will be a bit
larger (and Jeff's words seem "near approval" even after fixing the
tests, not complete approval).
Sounds perfect. Given the bulk of the review work is already done, the
final review ack will be easy.
jeff
