https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114732
--- Comment #6 from HaoChen Gui <guihaoc at gcc dot gnu.org> --- (In reply to Segher Boessenkool from comment #3) > 1001, 0101, 0011 I mean of course. > > In some ways CCmode models this better than CCFPmode, but we do not actually > model > the SO bit (bit 3) at all in CCmode. It is a nice feature of CCmode (that 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. > > So we really need st least three CC modes: > > -- 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), and > also like in the BCD insns; > -- Bit 0 is all-true, bit 2 is all-false, like in the vcmp* insns. > > Do we need some other CC mode as well? Doe we want separately named CC modes > 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 also > 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 invalid bit test? Or we need to create UNSPECs for overflow and invalid bit test. Thanks.
