Tamar Christina <tamar.christ...@arm.com> writes: >> > However because insn 35 only cares about 0 or !0 the shape doesn't matter. >> > So insn 34 will be eliminated by combine. >> > >> > This leaves insn and 31 and 35. Essentially only the compare + branch, >> > directly on the vector elements, which is what vec_cbranch is now >> > representing. >> > >> > The optab allows us to generate the paradoxical subregs to convert >> > Adv. SIMD registers into SVE ones, and the predicate mask to make >> > the operation safe. >> > >> > Without this, we have to rely on combine which (even if it could match >> > such long sequences) would have to not just replace the adv. simd + b >> > with an SVE + b, but also do all the predicate optimization in the one >> > single pattern. >> > >> > > What kind of compares do you expect us to generate? Any besides >> > > equality compares? >> > >> > Any compare is possible. Since SVE vector comparisons take all 6 >> > comparison operators, there's also floating point versions and >> > unordered variants. Basically in the ISA vectors are first class >> > control flow elements. >> > >> > > Why would we not allow cbranch to take an >> > > operand 0 that specifies the desired reduction? >> > >> > That's certainly possible, but that's just going to make cbranch itself >> > more complicated to understand. I chose to go with _any and _all >> > since as you say, for the branch comparison itself only != 0 and == 0 >> > makes sense. So cbranch would need to get two operators in this case >> > one for the branch comparison and one for the data comparison. >> > >> > i.e. if expanding >> > >> > a = b > c >> > if (a != 0) >> > >> > branch would get >> > (set (reg a) >> > (gt (reg b) (reg c)) >> > (clobber cc_nz) >> > (ne (reg a) 0) >> > (if_then_else ...) >> > >> > I basically opted for a simpler change, since you can only have != 0 and >> > == 0 >> > this is just encoded in the name "any" and "all" so we don't have to send >> > the >> > dummy operators along. >> >> Well, if we'd introduce ANY_LT_EXPR, ANY_NE_EXPR, ... ALL_LT_EXPR, >> ALL_NE_EXPR ... then we can have on GIMPLE >> >> if (a ANY_GT c) >> >> and no need for a separate compare and compare-and-branch. > > Yes, new comparison codes would work here too. > But then I'll need 12 of them.. But could do so if you prefer 😊 > > But you're right, conceptually my new optabs are introducing an > expand time only representation of these 12 operators. > [...] > I would have though that the two optabs would be preferrable to 12 new > comparison > operators, but could make those work too 😊
I assume we'd need ANY and ALL variants of: DEFTREECODE (UNLT_EXPR, "unlt_expr", tcc_comparison, 2) DEFTREECODE (UNLE_EXPR, "unle_expr", tcc_comparison, 2) DEFTREECODE (UNGT_EXPR, "ungt_expr", tcc_comparison, 2) DEFTREECODE (UNGE_EXPR, "unge_expr", tcc_comparison, 2) DEFTREECODE (UNEQ_EXPR, "uneq_expr", tcc_comparison, 2) since there is no way of representing the opposite condition without changing the trapping behaviour. For example, there's no non-trapping version of "ordered or GE" to complement "UNLT". If so, it'd be more than 12. Richard
