On Mon, Nov 28, 2022 at 09:42:05AM +0100, Richard Biener wrote:
> Since the function seems to be allowed to fail the patch looks
> reasonable - still I wonder
> what the "fallback" for a MODE_CC style compare-and-branch is? There
> are callers
> of this function that do not seem to expect failure at least, some
> suspiciously looking
> like MODE_CC candiates.
Hi!
cbranchcc4 is *not* a compare-and-branch, like ccbranch<mode>4 for other
modes are. Instead, it is a conditional branch. I still think it is a
bad idea to use this same pattern name for a completely different (and
much more basic) concept, it just confuses many things, makes us need
exceptions in most users of cbranch<mode>4 :-(
cbranchcc4 does not do a comparison. Instead, it uses the result of
some previous comparison in some CC register (or anything else that set
such a register). We want to use a cbranchcc4 to reuse some earlier
comparison here. Which is great of course! But, redoing the
(potentially expensive) computation to prepare the CC for a more
complicated condition is not a good idea. Also, Power's conditional
branch insns just branch on one of the 32 condition bits (either set or
unset), not on a logical combination of multiple of those bits, as we
need with LTGT, UNLT, UNGT, UNEQ, and LE and GE without fastmath. So it
is much cleaner (and causes fewer problems later on) if we only allow
those codes we do support.
Example of LTGT:
fcmpu 0,0,1 # compare f0 <=> f1 to cr0 (exactly one of
# cr0.lt, cr0.gt, cr0.eq, cr0.un will be set)
cror 2,0,1 # cr0.eq = cr0.lt | cr0.gt
beq 0 # branch if cr0.eq is set
So, we want the cbranchcc4 here to just do that last insn, not the last
two insns (or all three as any other cbranch<mode>4 is!)
Segher
