https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106322
--- Comment #41 from Kewen Lin <linkw at gcc dot gnu.org> ---
(In reply to Kewen Lin from comment #40)
> > >diff --git a/gcc/internal-fn.cc b/gcc/internal-fn.cc
> > >index d666ccccf67..7d8b4ac2200 100644
> > >--- a/gcc/internal-fn.cc
> > >+++ b/gcc/internal-fn.cc
> > >@@ -3750,7 +3750,12 @@ static bool
> > > direct_optab_supported_p (direct_optab optab, tree_pair types,
> > > optimization_type opt_type)
> > > {
> > >- machine_mode mode = TYPE_MODE (types.first);
> > >+ tree type = types.first;
> > >+ machine_mode mode = TYPE_MODE (type);
> > >+ /* Scalar mode optab can't work for vector type, return false if
> > >+ the given type is vector type but the mode isn't vector mode. */
> > >+ if (VECTOR_TYPE_P (type) != VECTOR_MODE_P (mode))
> > >+ return false;
> >
> > There are a few which scalar mode and vector types can differ and still
> > work: IOR, XOR, and AND. I wonder if those should be special cased here or
> > somewhere else.
>
> Good point! This is overkill then. Not sure if there is this kind of routine
> to special case them.
When I was cooking one function to special case Andrew's concerns, I realized
that the touched functions direct_optab_supported_p, convert_optab_supported_p
and multi_vector_optab_supported_p are only for optabs used in internal-fn.def,
for now there are not {and,ior,xor}_optab or their similars (I quickly went
through binary/unary ones). So it seems we don't need to consider this for now?
