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 tree-optimization/83359] [8 Regression] ICE in expand_LOOP_DIST_ALIAS, at internal-fn.c:2362


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

--- Comment #4 from rguenther at suse dot de <rguenther at suse dot de> ---
On Mon, 11 Dec 2017, amker at gcc dot gnu.org wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83359
> 
> --- Comment #3 from amker at gcc dot gnu.org ---
> (In reply to Richard Biener from comment #2)
> > Both loops guarded by the IFN are parallelized with the loop noted by
> > the IFN outlined and the autopar scalar copy being a new loop.
> > 
> > Not sure what to do best, eventually not processing those loops with
> > GRAPHITE/autopar and/or being more rigid in throwing it away.  In theory
> > expanding the IFN as just its arg is valid.
> 
> In current logic, we only keep distribution if it enables vectorization,  one
> possible fix is we also keep it if parallelization is enabled.  That is,
> resolve IFN_DIST call and keep the distribution in parallelization.  Does this
> make sense?

I guess so, but I'd like to investigate this a bit more.  One issue
is we outline the loop we reference from the IFN with parallelization,
this might be a strong enough hint to remove the IFN from autopar.

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