On Wed, 9 Jul 2025, Tamar Christina wrote:
> > > +Operand 0 is a comparison operator. Operand 1 and operand 2 are the
> > > +first and second operands of the comparison, respectively. Operand 3
> > > +is the @code{code_label} to jump to.
> > > +
> > > +@cindex @code{cbranch_all@var{mode}4} instruction pattern
> > > +@item @samp{cbranch_all@var{mode}4}
> > > +Conditional branch instruction combined with a compare instruction on
> > > vectors
> > > +where it is required that at all of the elementwise comparisons of the
> > > +two input vectors are true.
> >
> > See above.
> >
> > When I look at the RTL for aarch64 I wonder whether the middle-end
> > can still invert a jump (for BB reorder, for example)? Without
> > a cbranch_none expander we have to invert during RTL expansion?
> >
>
> Isn't cbranch_none just cbranch_all x 0? i.e. all value must be zero.
> I think all states are expressible with any and all and flipping the branches
> so it shouldn't be any more restrictive than cbranch itself is today.
>
> cbranch also only supports eq and ne, so none would be cbranch (eq x 0)
>
> and FTR the RTL generated for AArch64 (Both SVE And Adv.SIMD) will be
> simplified to:
>
> (insn 23 22 24 5 (parallel [
> (set (reg:VNx4BI 128 [ mask_patt_14.15_57 ])
> (unspec:VNx4BI [
> (reg:VNx4BI 129)
> (const_int 0 [0x0])
> (gt:VNx4BI (reg:VNx4SI 114 [ vect__2.11 ])
> (const_vector:VNx4SI repeat [
> (const_int 0 [0])
> ]))
> ] UNSPEC_PRED_Z))
> (clobber (reg:CC_NZC 66 cc))
> ]) "cbranch.c":25:10 -1
>
> (jump_insn 27 26 28 5 (set (pc)
> (if_then_else (eq (reg:CC_Z 66 cc)
> (const_int 0 [0]))
> (label_ref 33)
> (pc))) "cbranch.c":25:10 -1
> (int_list:REG_BR_PROB 1014686025 (nil))
>
> The thing is we can't rid of the unspecs as there's concept of masking in RTL
> compares.
> We could technically do an AND (and do in some cases) but then you lose the
> predicate
> Hint constant in the RTL which tells you whether the mask is known to be all
> true or not.
> This hint is crucial to allow for further optimizations.
>
> That said the condition code, branch and compares are fully exposed.
>
> We expand to a larger sequence than I'd like mostly because there's no support
> for conditional cbranch optabs, or even conditional vector comparisons. So
> the comparisons
> must be generated unpredicated by generating an all true mask, and later
> patterns
> merge in the AND.
>
> The new patterns allow us to clean up codegen for Adv.SIMD + SVE (in a single
> loop)
> But not pure SVE. For which I take a different approach to try to avoid
> requiring
> a predicated version of these optabs.
>
> I don't want to push my luck, but would you be ok with a conditional version
> of these
> optabs too? i.e. cond_cbranch_all and cond_cbranch_all? This would allow us
> to
> immediately expand to the correct representation for both SVE and Adv.SIMD
> without having to rely on various combine patterns and cc-fusion to optimize
> the sequences
> later on (which has historically been a bit hit or miss if someone adds a new
> CC pattern).
Can you explain? A conditional conditional branch makes my head hurt.
It's really a cbranch_{all,any} where the (vector) compare has an
additional mask applied? So cbranch_cond_{all,any} would be a better
fit? Though 'cond_' elsewhere suggests there is an else value, instead
cbranch_mask_{all,any}? Or would that not capture things exactly?
cbranch is compare-and-branch, so masked-compare-and-branch aka
mcbranch[_{all,any}]?
And writing this and not tryinig to remember everything said it
appears that 'cbranch' itself (for vectors) becomes redundant?
Richard.
> And the reason for both is that for Adv.SIMD there's no mask at GIMPLE level
> and we have to
> make it during expand.
>
> Thanks,
> Tamar
>
--
Richard Biener <rguent...@suse.de>
SUSE Software Solutions Germany GmbH,
Frankenstrasse 146, 90461 Nuernberg, Germany;
GF: Ivo Totev, Andrew McDonald, Werner Knoblich; (HRB 36809, AG Nuernberg)
