[PATCH] D18110: [OpenMP] Fix SEMA bug in the capture of global variables in template functions.

[Carlo Bertolli via cfe-commits]

carlo.bertolli added a comment.

Hi Alexey

I understand your concerns and share the danger of working on optimizations before a correct implementation is actually in place.
I do not think this is the case. My comment was very precise about the cause-effect: the OpenMP specification was defined in a certain way, and that is what we should implement, and the consequence of that is an optimized implementation compared to what we had in OpenMP 4.0.

Here are the passages of the OpenMP specifications where I think this is specified (from OpenMP 4.5 specification text):

- Page 197, description of firstprivate: "A list item that appears in a firstprivate clause is subject to the private clause semantics described in Section 2.15.3.3 on page 192, except as noted. In addition,** the new list item is initialized from the original list item existing before the construct**."

- Page 105, restrictions of target: "If an array section is a list item in a map clause and the array section is derived from a variable for which the type is pointer then the data-sharing attribute for that variable in the construct is firstprivate. Prior to the execution of the construct, **the private variable is initialized with the address of the storage location of the corresponding array section in the device data environment**."

- Page 105, following paragraph: "If a zero-length array section is a list item in a map clause, and the array section is derived from a variable for the which the type is pointer then** that variable is initialized with the address of the corresponding storage location in the device data environment**."

In this I read that whenever we have a map with an array section, or a map on a zero-length array section, or a firstprivate on any kind of variable, we need to copy the value of the variable (scalar, pointer) into the corresponding private variable.

Implementing this with references would work indeed, but it would be like implementing pass-by-value using references.

We had long discussion about this with various members of the OpenMP committee on how to implement this correctly. This is why I am insisting on this not being an optimization.

However, this may not apply here (that is why I conditioned by previous comment) or you still think that we should always pass references for any kind of argument to target regions. It is your call, but I wanted to make sure that this is put in the right light.

Thanks!

- Carlo


http://reviews.llvm.org/D18110