[Openmp-commits] [PATCH] D60972: [OpenMP 5.0] libomptarget interface for declare mapper functions

[Lingda Li via Phabricator via Openmp-commits]

lildmh added a comment.

In D60972#1529151 <https://reviews.llvm.org/D60972#1529151>, @Hahnfeld wrote:

> In D60972#1529083 <https://reviews.llvm.org/D60972#1529083>, @lildmh wrote:
>
> > In D60972#1528662 <https://reviews.llvm.org/D60972#1528662>, @Hahnfeld wrote:
> >
> > > It would be great to have such things in public...
> >
> >
> > Sure, there is no secret. Please see it here if you are interested: https://github.com/lingda-li/public-sharing/blob/master/mapper_runtime_design.pptx
>
>
> From a quick look, I'd say this does not reflect the current design: The types are named differently, have a different layout (SoA vs AoS) and there's no implementation of `__tgt_target_mapper` in this patch as @grokos mentioned.


Hi Jonas, starting from slide 8 is the current design, `__tgt_target_mapper` etc. are deprecated. It may not accurately reflect the current code but the framework should be the same.

> Moreover, I'd question the following things:
> 
> 1. Why are we back to `__kmpc_?` naming? Most other functions specific to libomptarget are called `__tgt_?`.

There are other functions in libomptarget starting with `__kmpc_`, for example, `__kmpc_push_target_tripcount`.
My understanding is anything that does not directly call the device starting with `__kmpc_`. The IBM and Intel compiler people seem to be okay with this naming.

> 2. Do you really want to construct `std::vector`s in the compiler generated code? That's bound to cause trouble with Fortran, isn't it?

The compiler doesn't generate code related to `std::vector`. It's only used in the runtime implementation, so it should be okay with Fortran. Again, the IBM and Intel compiler people seem to agree with it.


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D60972/new/

https://reviews.llvm.org/D60972