> -----Original Message-----
> From: Alfie Richards <[email protected]>
> Sent: 25 September 2026 13:56
> To: Tamar Christina <[email protected]>; [email protected]
> Cc: nd <[email protected]>; [email protected]
> Subject: Re: [patch 8/14]middle-end: allow vector branches to consume
> conditional compare IFNs
>
> On 14/09/2026 10:27, Tamar Christina wrote:
> > That means the IFNs fail the check in ssa_is_replaceable_p. This adds a
> promise
> > essentially that if you see the IFN in the IL then the producer has checked
> > it
> and
> > it's TER safe.
> >
> > This then updates the vec_cbranch_* code to support the new COND_*
> IFNs. Without
> > this we regress codegen to
> >
> > cmpgt p1.s, p0/z, z0.s, z1.s
> > ptest p0, p1.b
> > b.ne .Lhit
> >
> > and after this patch, branch expansion can see the compare IFN directly and
> pass
> > the original compare through the normal target compare-and-branch
> machinery:
> >
> > cmpgt p1.s, p0/z, z0.s, z1.s
> > b.any .Lhit
>
> Hi Tamar,
>
> Sorry I don't understand the context for this change or what TER is really.
>
> But I'm curious why we don't allow the former code gen and clean it up
> in RTL combine in the backend?
>
> Seems like it could be a general pattern and optimization?
Because Combine cannot do it.
Without this optimization
1. the compare result would have two uses. One in the branch one outside
the branch. Combine will refuse to combine. To fix this a later
earlier patch splits the use and as a result you now have a compare and
a vector cbranch.
2. SVE Vector compares are expanded as unpredicated vector compares with
a hint that says the mask (which is forced to a register is KNOWN_PTRUE).
This means that the compare in the if is masked out of expand, and the other
compare is unmasked and somewhere there's a bit_and_expr that applies a
mask.
3. The backend then has many very large patterns that find compares with
A known PTRUE hint, and a mask and at combine time makes the predicated
compare. It's only at this point, that the duplicate compares are the same.
But then there are no passes that can combine them after combine. After
combine
we have no CSE pass, we have GCSE but we're out of cfg after combine so
it's very
conservative. So you end up with duplicate compares. Compare elimination
could
potentially eliminate it, but the REGNOs for the arguments may not match.
4. Pushing the mask in before expand, means all the complicated patterns around
compare can be simplified.
So it's not really a "general pattern" also removing ptest doesn't work that
easily
because of how the architecture defined the use. Ptest elimination can't be done
as a pattern as you need the instruction *including* the uses of the CC flags.
The point of this patch is to simplify things early on so that optimizations
become
Simpler to do.
Thanks,
Tamar
>
> KR,
> Alfie
>
> >
> > Tests for this are the existing vec_cbranch tests which fail.
