This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
[Bug tree-optimization/83359] [8 Regression] ICE in expand_LOOP_DIST_ALIAS, at internal-fn.c:2362
- From: "rguenther at suse dot de" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: Mon, 11 Dec 2017 10:41:48 +0000
- Subject: [Bug tree-optimization/83359] [8 Regression] ICE in expand_LOOP_DIST_ALIAS, at internal-fn.c:2362
- Auto-submitted: auto-generated
- References: <bug-83359-4@http.gcc.gnu.org/bugzilla/>
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.