Re: [PATCH] Add a new conversion for conditional ternary set into ifcvt [PR106536]

[Segher Boessenkool <segher@kernel.crashing.org>]

Hi!

On Thu, Nov 24, 2022 at 11:24:15AM +0100, Richard Biener wrote:
> On Thu, Nov 24, 2022 at 8:25 AM HAO CHEN GUI <guihaoc@linux.ibm.com> wrote:
> > 在 2022/11/24 4:06, Richard Biener 写道:
> > > Wouldn't we usually either add an optab or try to recog a canonical
> > > RTL form instead of adding a new target hook for things like this?
> >
> > Thanks so much for your comments. Please let me make it clear.
> >
> > Do you mean we should create an optab for "setb" pattern (the nested
> > if-then-else insn) and detect candidate insns in ifcvt pass? Then
> > generate the insn with the new optab?
> 
> Yes, that would be one way to do it.  Another way would be to
> generate a (to be defined) canonical form of such instruction and
> see whether it can be recognized (whether there's a define_insn
> for it).

But these insns are most useful when they come up "naturally", so we
really have to recognise many formulations of it separately.

The machine insn  setb x,BF  returns:
  { -1,  if BF.0 is set
  { 1,   if BF.1 is set
  { 0,   otherwise
This "otherwise" includes when a floating point comparison returned
"unordered" (BF.3, set if an operand was NaN), and BF.2 ("equal").  If
the comparison was only three-way (integer or fast-math) it is natural
to test for equality first (given we always have exactly one of the
first three BF bits set in that case!)

> Note that were just things that came into my mind here, I'm not too
> familiar with how we handle such situations but at least I'm not
> aware of dozens of target hooks to handle instruction availability.

In similar cases I never could up with anything that worked better than
recognising all possible patterns, unfortunately.  We can do a predicate
for that though, there is no need to write it out all over the place :-)


Segher