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...
