[Bug target/68577] [6 Regression] ICE: in expand_direct_optab_fn, at internal-fn.c:2171

["rsandifo at gcc dot gnu.org" <gcc-bugzilla at gcc dot gnu dot org>]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68577

rsandifo at gcc dot gnu.org <rsandifo at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |ASSIGNED
   Last reconfirmed|                            |2015-11-30
           Assignee|unassigned at gcc dot gnu.org      |rsandifo at gcc dot gnu.org
     Ever confirmed|0                           |1

--- Comment #2 from rsandifo at gcc dot gnu.org <rsandifo at gcc dot gnu.org> ---
(In reply to Jakub Jelinek from comment #1)
> Bet this started with r230475 or so.
> The problem is that these builtins are in scalar form always returning int,
> but take some argument of wider bitsize.
> The vectorizer thinks the target can handle narrowing conversion builtin,
> and thus emits:
>   vect_l.17_53 = [vec_unpack_lo_expr] vect_vec_iv_.15_49;
>   vect_l.17_54 = [vec_unpack_hi_expr] vect_vec_iv_.15_49;
>   vect__7.18_55 = POPCOUNT (vect_l.17_53, vect_l.17_54);
> where vec_l.17 has V2DImode, and vect__7.18 has V4SImode.
> But at least the power8 popcountv2di2 pattern takes a single V2DImode
> argument (rather than 2 V2DImode arguments) and returns a V2DImode result,
> while the caller expects one that takes two V2DImode arguments and produces
> 4 results in V4SImode vector for that.
> 
> So, first of all, what do we expect from the backends, shall they implement
> these popcount<mode>2 expanders for vector modes as returning the result in
> the same mode as the single argument (then the vectorizer needs to be told
> about that and needs to do the narrowing manually, do e.g. in the above case
> do POPCOUNT on each V2DImode argument separately, then combine the two
> V2DImode results as for long -> int vectorized conversion.  Or they need to
> do something different, but then the question is if it should be called
> popcountv2di2 if it actually takes 2 arguments rather than 1, etc.

Yeah, I think we should be doing the first one (defining the optab
naturally and leaving the vectoriser to fix things up).  Working on
a patch...