[Openmp-commits] [PATCH] D60972: [OpenMP 5.0] libomptarget interface for declare mapper functions
Lingda Li via Phabricator via Openmp-commits
openmp-commits at lists.llvm.org
Tue Jun 4 07:08:45 PDT 2019
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
More information about the Openmp-commits