This is the mail archive of the gcc-patches@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]

Re: [PATCH] Fix ICE with inlining and #pragma omp simd (PR fortran/77665)


On Wed, 21 Sep 2016, Alexander Monakov wrote:

> On Wed, 21 Sep 2016, Jakub Jelinek wrote:
> > The simduid pass uses the cfun->has_simduid_loops flag to determine if it
> > needs to clean up any left-over GOMP_SIMD_* internal functions.
> > During inlining, we set the flag if we inline some loop with simduid, or if
> > we find GOMP_SIMD_ORDERED_* internal call, but the testcase shows that we
> > need to do that for the other GOMP_SIMD_* ifns too, because what we inline
> > might have turned the loop->simduid loops into non-loops (or they might not
> > exist from the beginning because simd region had noreturn body).
> 
> I think this means that the comment at the declaration of has_simduid in
> function.h needs to be updated.
> 
> I see that there are other places in the compiler that propagate the has_simduid
> property. Now that the property is tied to just the presence of GOMP_SIMD_xyz
> IFNs, won't those other places need changes too?
> 
> I wonder why this property is propagated with such fine granularity in the first
> place. Wouldn't it be simpler and almost as efficient to propagate it on the
> function basis, i.e. when inlining A into B set it on B if A had it, without
> regard for whether uses in A have already been DCE'd?

That would indeed simplify things but the patch is ok as-is with me as 
well.

Thanks,
Richard.


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