On Wed, Nov 16, 2022 at 06:06:19AM -0600, Segher Boessenkool wrote: > Hi guys, > > On Tue, Nov 15, 2022 at 10:04:04PM -0500, David Edelsohn wrote: > > On Tue, Nov 15, 2022 at 9:32 PM HAO CHEN GUI <guih...@linux.ibm.com> wrote: > > > The patch enables have_cbrnachcc4 which is a flag in ifcvt.cc to > > > indicate if branch by CC bits is invalid or not. As rs6000 already has > > > "*cbranch" insn which does branching according to CC bits, the flag > > > should be enabled and relevant branches can be optimized out. The test > > > case illustrates the optimization. > > cbranch<mode>4 normally compares the <mode>mode operands 2 and 3, and > jumps to operands[0] if operands[1] (a relation of operands 2 and 3) is > true. See emit_cmp_and_jump_insns for example. But cbranchcc4 does > not do any comparison; instead, it branches based on the result of a > previous comparison, stored in operands[2], and operands[3] has to be > const_int 0.
Apparently the operand order is different? Where is that documented at all anyway? Grr. Please adjust my comments to taste :-/ Segher
