!$omp target device(0) map(to : min_limit,max_limit) not working

[jimdempseyatthecove]

In Poor speed in MIC you will find a test case that exhibits a failure of the map(... clause of !$omp target device(0) not copying data to/from the device. The workaround was to use !$omp target update to(.. before, and !$omp target update from( after the !$omp target device(0) region.

Windows 7 Pro x64, IVF V16.0 update 1.

Look for commented out "!*!$omp ... clauses

When you remove the comment "!*", please insert the comment on the target update directives. That should produce the test case.

Note, for testing reduce the value of max_limit=100000000 to some number much lower (100 will do).

Jim Dempsey

[Kevin_D_Intel]

I'll have a look, Jim. Thank you.

[Rajiv_D_Intel]

The variables nthreads, starttime, finishtime and count are in a module and therefore statically allocated (in C terms). These variables are always mapped and therefore the only way to cause their transfer to/from the CPU is explicit omp target update.

[jimdempseyatthecove]

In the example given, those variables are stack scalars:

  program prime_count
      use omp_lib
      implicit none
      integer::min_limit,max_limit
      integer::count,nthreads

Besides, the map clause can map both stack local and shared ("static" in module or COMMON, or SAVE in local procedure).

Jim Dempsey

[Rajiv_D_Intel]

In the example in the other thread titled "Poor speed in MIC" the variables are in a module.

Perhaps you should post the code again so we can be sure to be talking about the same example.

Even though omp target can refer to stack-locals, and save variables, variables in a module will need explicit target update.

[jimdempseyatthecove]

When I click on the link in post #1, there is no module listed???

Jim Dempsey

[Rajiv_D_Intel]

The second longer example has the commented out code you mention, replaced with target update to, and that example places the variables in a module.

[jimdempseyatthecove]

Rajiv,

From the IVF V16.0 Update 1 reference:

If original and corresponding list items share storage, data races can result when intervening synchronization between tasks does not occur. If variables that share storage are mapped, it causes unspecified behavior.

When a corresponding list item of the original list item is in the data environment of the device associated with the construct:

• The new device data environment uses the corresponding list item from the enclosing device data environment.

• No additional storage is allocated in the new device data environment.

• Initialization and assignment are not performed, regardless of the map-type that is specified.

When a corresponding list item is not in the data environment of the device associated with the construct:

• A new list item is derived from the original list item; it becomes the corresponding list item in the new device data environment.

• Storage is allocated for the new list item. It has the same type, type parameter, and rank as the original list item.

• Initialization and assignment are performed if specified by the map-type.

I see.

Jim Dempsey

[jimdempseyatthecove]

IMHO it is unfortunate that it does not perform the assignment (allocation if required is a different matter).

Jim Dempsey