This is the mail archive of the gcc-bugs@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[Bug target/78938] [7 Regression] ICE in expand_vec_cond_expr, at optabs.c:5636 w/ -mavx512bw -ftree-loop-vectorize -O1


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

--- Comment #5 from rguenther at suse dot de <rguenther at suse dot de> ---
On Wed, 4 Jan 2017, jakub at gcc dot gnu.org wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78938
> 
> --- Comment #4 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
> (In reply to rguenther@suse.de from comment #3)
> > I believe the bool patterns were supposed to handle this case but
> > at the time I fixed its time/size complexity issues we IIRC ended up
> > effectively disabling them for x86 with no fallout -- this may be
> > the fallout.  So I'd figure out why the bool patterns stuff does not
> > trigger here first.  IIRC the "effective disabling" was due to
> > some target optab/hook check that always returns true on x86
> > (and thus possibly needs to be changed to check for a bad "mix" of
> > VECTOR_BOOLEAN kinds)
> 
> The bool patterns generally do something different, attempt to translate bool
> operations into integral operations of some reasonable size.  That is not what
> is needed here.  Anyway, before we talk about vect patterns, the first question
> is if vectorizable_condition should handle this by itself (increase its
> complexity), or fail.  If the latter, then after it fails there is another
> question if we want to do something about it in tree-vect-patterns.c or not.

Yes, the vectorizer should handle it (and I always prefer handling
things in vectorizable_* rather than adding complexity to patterns).

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]