[Openmp-commits] [PATCH] D44186: [OpenMP] New clang/libomptarget map interface: remove translation code

Ravi Narayanaswamy via Phabricator via Openmp-commits openmp-commits at lists.llvm.org
Wed Mar 7 13:24:53 PST 2018

RaviNarayanaswamy added inline comments.

Comment at: libomptarget/src/omptarget.cpp:197-199
+    // Adjust for proper alignment if this is a combined entry (for structs).
+    // Look at the next argument - if that is MEMBER_OF this one, then this one
+    // is a combined entry.
grokos wrote:
> Hahnfeld wrote:
> > grokos wrote:
> > > Hahnfeld wrote:
> > > > I thought this is now done in the compiler?
> > > No, it's not. The compiler could take care of this issue, but it's not its job. The compiler should just inform the runtime that we requested a mapping starting from some address. If `CUDA memcpy`, for instance, has some requirements regarding the alignment of addresses, that's not the compiler's business. The compiler doesn't and shouldn't care about what happens at the plugin level of libomptarget.
> > If that's specific to CUDA, why does it happen in the plugin agnostic part of libomptarget?
> That's a good point. A more elegant solution would be to extend the plugin interface (`__tgt_rtl_*` functions) with a new function which the agnostic library can query in order to get any alignment requirements. I'm in favour of this approach, but I need to ask other people what they think. In any case, implementing this potential change is not part of this patch. Thoughts?
I am not sure what you are trying to do here.  For structure members, the compiler should generate the begin address, offset and size.  The code generated for  the target is using the beginning of the struct to access the field.  So cannot just pad the field member.

  rOMP OpenMP


More information about the Openmp-commits mailing list