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

[Jonas Hahnfeld via Phabricator via Openmp-commits]

Hahnfeld 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.
----------------
RaviNarayanaswamy wrote:
> 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.
Good point, this needs clarification. Maybe @grokos could share a code example where this padding is needed and point to documentation where it says that `cuMemcpy` can only handle aligned pointers?

My guess which might be completely wrong: Maybe the begin address is just for transfer and the target code will use the subsequent entries which point to the member directly?


Repository:
  rOMP OpenMP

https://reviews.llvm.org/D44186