On Fri, May 07, 2021 at 10:20:11PM +0200, Thomas Schwinge wrote:
> Hi!
>
> I'm currently working on an OpenACC thing, which in 'omp-low' separately
> for each OpenACC 'loop' construct, collects variable declarations
> referenced in 'private' clauses as well as those from inner binds
> (simplified). Accidently that was also enabled for OpenMP, and for a few
> testcases of OpenMP 'simd', I found unexpected nesting of variable
> declaration in bind vs. 'private' clause.
>
> I'm having a check that each variable declaration encounter has not yet
> been seen for the respective context, and there are a few testcases where
> this triggers, all involving OpenMP 'simd', and all seem to exhibit the
> similar pattern, that in the 'gimple' dump, we have:
>
> #pragma omp simd [...] private(D.2992)
> for ([...])
> {
> {
> const difference_type D.2992;
>
> Notice that's a 'private' clause (created during gimplification?)
> referring to a variable declaration of an *inner* bind. In our code, the
That is intentional for TREE_ADDRESSABLE variables inside of simd, see
r10-2271-gd81ab49d0586fca0f3ee2f49c4581dd02508fcca
Even if they are local to the body, as they are addressable, we need to
ensure they are omplowered as the SIMD magic arrays, otherwise different
iterations could access the same copy and because we tell vectorizer
etc. the iterations are safe to be vectorized or even independent, we would
miscompile things.
This is the only exception when this happens and is a temporary thing from
the gimplification till OpenMP lowering/expansion.
Jakub
