Ping? Does anyone have any opinions on how this issue should be resolved?
On 09/07/2021 12:16 pm, Kwok Cheung Yeung wrote:
3) In the OpenMP examples (version 5.0.1), section 9.7, the example
metadirective.3.c does not work as expected.
#pragma omp declare target
void exp_pi_diff(double *d, double my_pi){
#pragma omp metadirective \
when( construct={target}: distribute parallel for ) \
default( parallel for simd)
...
int main()
{
...
#pragma omp target teams map(tofrom: d[0:N])
exp_pi_diff(d,my_pi);
...
exp_pi_diff(d,my_pi);
In the first call to exp_pi_diff in an '#pragma omp target' construct, the
metadirective is expected to expand to 'distribute parallel for', but in the
second (without the '#pragma omp target'), it should expand to 'parallel for simd'.
During OMP expansion of the 'omp target', it creates a child function that calls
exp_pi_diff:
__attribute__((omp target entrypoint))
void main._omp_fn.0 (const struct .omp_data_t.12 & restrict .omp_data_i)
{
...
<bb 4> :
__builtin_GOMP_teams (0, 0);
exp_pi_diff (d.13, my_pi);
This is not a problem on the offload compiler (since by definition its copy of
exp_pi_diff must be in a 'target'), but if the host device is used, the same
version of exp_pi_diff is called in both target and non-target contexts.
What would be the best way to solve this? Offhand, I can think of two solutions:
(a) Recursively go through all functions that can be reached via a target region
and create clones for each, redirecting all function calls in the clones to the
new cloned versions. Resolve the metadirectives in the clones and originals
separately.
Maybe this could be done at the same time as when marking functions implicitly
'declare target'? It seems a lot of work for one special case though...
(b) Make the construct selector a dynamic selector when OpenMP 5.1 metadirective
support is implemented. Keep track of the current construct list every time an
OpenMP construct is entered or exited, and make the decision at runtime.
I think this would be easier to implement at runtime (assuming that the
infrastructure for OpenMP 5.1 was already in place) since this a host-side
issue, but it probably goes against the intent of the specification, given that
the 'construct' selector set appeared in the 5.0 specification before dynamic
replacements became available.
Thanks
Kwok