From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id 9E9C73858D35; Wed, 17 Apr 2024 05:35:33 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 9E9C73858D35 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org; s=default; t=1713332133; bh=XeVCeZcJpOMjvkOy/W5Oo5woSEwpu7j+ZcUXBGG0mvY=; h=From:To:Subject:Date:In-Reply-To:References:From; b=vdWLwK+75q8LbEpZmMtwb5cxyR4vb7rC8bPyB3jOcdNIx+f7Dmry3pFZr5k5lw5Sm rX7X2QBlz3r4UFOYlDFUPh8W8CUitVZKegLBrV9olpd2/YGIOHop45AkR+wTdMkJNW ljOUNfVpussxBY0jUW0V8/QQKaFsu2/Hs63Cg08w= From: "guihaoc at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug target/114732] ge can't be reversed to unlt for bcd compares Date: Wed, 17 Apr 2024 05:35:32 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: target X-Bugzilla-Version: 14.0 X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: guihaoc at gcc dot gnu.org X-Bugzilla-Status: UNCONFIRMED X-Bugzilla-Resolution: X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: guihaoc at gcc dot gnu.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 List-Id: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D114732 --- Comment #6 from HaoChen Gui --- (In reply to Segher Boessenkool from comment #3) > 1001, 0101, 0011 I mean of course. >=20 > In some ways CCmode models this better than CCFPmode, but we do not actua= lly > model > the SO bit (bit 3) at all in CCmode. It is a nice feature of CCmode (tha= t we > actually use as fundamental, in the backend code) that CCmode always has > exactly > one of three bits "hot" (and CCFPmode always one of four). Bit 3 (SO) in > CCmode > is treated as not being part of the CC really, but an extra thing. This > doesn't > work all that well of course. >=20 > So we really need st least three CC modes: >=20 > -- Exactly one of bits 0..3 hot, like CCFPmode; > -- Exactly one of bits 0..2 hot, bit 3 independently set, like CCmode (and > that independent bit 3 modeled nicely as well, unlike what we have), a= nd > also like in the BCD insns; > -- Bit 0 is all-true, bit 2 is all-false, like in the vcmp* insns. >=20 > Do we need some other CC mode as well? Doe we want separately named CC m= odes > for the different variants of this (like the integer CC mode vs. the BCD > one)? > We already have a separate CCUNSmode which is exactly like CCmode, as far= as > the hardware cares, but the meaning is different (for CCUNS the LT and GT > bits > are set based on an unsigned integer compare, not a signed one). There a= lso > is CCEQmode, which has only bit 2 valid (we use it for constructing one CR > bit > from others, like with cror or crnot). Thanks for your comment. We also have VSX scalar test data class (xststdc* insns) which use bit 0 as sign and bit 2 as matched. I think they can share with vcmp* insns. Could you advice if rtl code "unorder" is suitable for bcd overflow and inv= alid bit test? Or we need to create UNSPECs for overflow and invalid bit test. Thanks.=