Hi! On Mon, 16 Dec 2013 16:38:18 +0100, Jakub Jelinek <ja...@redhat.com> wrote: > On Mon, Dec 16, 2013 at 08:41:02AM +0100, Thomas Schwinge wrote: > > Here is the patch I propose for gomp-4_0-branch; OK? > > No. The reason for 3 separate arrays is that some of the values > are always variable, some are sometimes variable (sizes), some are > never variable (alignment + kind). > So, if anything, the change would be to make the last array ushort instead of > uchar.
Sure, that's fine by me, and thanks for the explanation. > Plus, the change, being an ABI change, would need to be done on the > trunk rather than just on gomp-4_0-branch. It's not an ABI change, as I had limited the change to the GOACC_parallel function, which does not yet exist in trunk. I can certainly prepare this ABI change for trunk if you'd like this seen changed for OpenMP, too. (Which I had proposed earlier, but not received comments on, so I went on with the solution I posted.) > But, I don't have time right now to read the OpenACC standard and am not > convinced whether it is actually desirable to use the same library > entrypoint for OpenACC when it clearly isn't a 1:1 match in behavior. We're not using the same entry points. We have GOACC_parallel, and will be adding more. Internally in libgomp, GOACC_parallel currently invokes the existing GOMP_target, because that is close enough to get something to work, even if not particularly complying with the OpenACC semantics (as we discussed), but that's only a stop-gap solution. Sorry if that wasn't obvious. At the GNU Tools Cauldron, I've been asked (at least by Jeff Law, maybe others, too) that we send incremental patches instead of just »big blobs of code after having worked on it for months« (approximation of Jeff's words), so that's what I'm trying. > You'll need extra code to implement the forceful mapping/unmapping even when > something is already mapped (OpenMP doesn't have that), also from your > example it wasn't clear if GOMP_target_data/GOMP_target_data_end map to > anything in OpenACC (it looked like you have separate enter and exit > directives for the region rather than one with structured block, and you can > supply clauses on either of them). Right, in OpenACC, there are several possibilities of setting up and retiring memory mapping regions. We're preparing patches for extending the existing libgomp memory mapping code to also satisfy the OpenACC requirements additionally to the existing OpenMP ones. At this point, and as we add support for additional OpenACC constructs and data clauses, we'll then be able to use the libgomp code with the OpenACC semantics, without duplicating the existing code implementing the OpenMP semantics. Grüße, Thomas
pgp1pFjysk90P.pgp
Description: PGP signature
