On 10/27/2014 12:48 AM, Zhenqiang Chen wrote: > >> -----Original Message----- >> From: Richard Henderson [mailto:r...@redhat.com] >> Sent: Saturday, October 11, 2014 11:32 PM >> To: Zhenqiang Chen; gcc-patches@gcc.gnu.org >> Subject: Re: [Ping] [PATCH, 6/10] aarch64: add ccmp CC mode >> >> On 09/22/2014 11:44 PM, Zhenqiang Chen wrote: >>> + case CC_DNEmode: >>> + return comp_code == NE ? AARCH64_NE : AARCH64_EQ; >>> + case CC_DEQmode: >>> + return comp_code == NE ? AARCH64_EQ : AARCH64_NE; >>> + case CC_DGEmode: >>> + return comp_code == NE ? AARCH64_GE : AARCH64_LT; >>> + case CC_DLTmode: >>> + return comp_code == NE ? AARCH64_LT : AARCH64_GE; >>> + case CC_DGTmode: >>> + return comp_code == NE ? AARCH64_GT : AARCH64_LE; >>> + case CC_DLEmode: >>> + return comp_code == NE ? AARCH64_LE : AARCH64_GT; >>> + case CC_DGEUmode: >>> + return comp_code == NE ? AARCH64_CS : AARCH64_CC; >>> + case CC_DLTUmode: >>> + return comp_code == NE ? AARCH64_CC : AARCH64_CS; >>> + case CC_DGTUmode: >>> + return comp_code == NE ? AARCH64_HI : AARCH64_LS; >>> + case CC_DLEUmode: >>> + return comp_code == NE ? AARCH64_LS : AARCH64_HI; >> >> I think these should return -1 if comp_code is not EQ. Like the CC_Zmode >> case below. > > Since the code can not guarantee that the CC is used in cbranchcc insns when > expand, it maybe in a tmp register. After some optimizations the CC is > forwarded in cbranchcc insn. So the comp_code might be any legal COMPARE.
Um, no. The point of returning -1 is to avoid combining with comparisons for which we cannot produce the proper result. E.g. the existing CC_Zmode, where only the Z bit is valid. We want to reject combination with LTU, which checks the C bit. Are you honestly suggesting that using CC_DNEmode with GE can be made to make sense in any way? r~