On Thu, Jan 29, 2026 at 7:23 PM Jeffrey Law
<[email protected]> wrote:
>
>
>
> On 1/28/2026 6:01 PM, Andrew Pinski wrote:
> > Currently if the rtl is either an arithmetic or an unary
> > rtl, noce_can_force_operand checks to see if there is an
> > optab for that rtl code. This works for more things except
> > on some targets they have a ss_minus instruction but don't
> > implement the optab for it. In the case of arm you can
> > generate a ss_minus with a builtin and then when it comes
> > to trying to do ifcvt, force_operand fails over.
> > In this case the optab, sssub was only supported for
> > fixed-point modes before and it was working as code_to_optab
> > would return there was not optabs. But after r15-1030-gabe6d39365476e,
> > the optab will be return. What the backend is doing is correct and will
> > most likely happen with other rtl codes/optabs later on.
> >
> > To fix this instead of just returning true if the optab exists, we need
> > to check if the optab entry for the mode exists.
> >
> >       PR rtl-optimization/122170
> >
> > gcc/ChangeLog:
> >
> >       * ifcvt.cc (noce_can_force_operand): Don;t only check if
> >       there is an optab for the code check the entry for the
> >       mode is non-null.
> I'm going to assume the special case for DIV is desirable.  Nit in the
> ChangeLog, replace the semicolon with a single quote.
>
> OK with that change, assuming I'm right about the desire to special case
> DIV.

Yes it should be a special case as that is how it is handled in force_operand.
I added the note about div to the changelog too.
Attached is the full patch which I pushed.


Thanks,
Andrew Pinski

>
> jeff

Attachment: 0001-ifcvt-Improve-noce_can_force_operand-in-ifcvt-PR1221.patch
Description: Binary data

Reply via email to