[Openmp-commits] [PATCH] D112154: [OpenMP][NFCI] Cleanup new device RT mapping interface

[Shilei Tian via Phabricator via Openmp-commits]

tianshilei1992 added inline comments.


================
Comment at: openmp/libomptarget/DeviceRTL/src/Mapping.cpp:232-239
-extern "C" {
-__attribute__((noinline)) uint32_t __kmpc_get_hardware_thread_id_in_block() {
-  return mapping::getThreadIdInBlock();
-}
-
-__attribute__((noinline)) uint32_t __kmpc_get_hardware_num_threads_in_block() {
-  return mapping::getNumberOfProcessorElements();
----------------
JonChesterfield wrote:
> jhuber6 wrote:
> > jdoerfert wrote:
> > > jhuber6 wrote:
> > > > Why do we want to get rid of these? I thought the idea was to keep these functions so we can generate generic IR in Clang that gets dispatched by the runtime once it's linked in.
> > > I think we should replace runtime call folding with store->load forwarding. The new runtime does generic store->load forwarding for IsSPMD, as an example, and it works better as we do not need to keep calls around. That said, there is an argument made for both to exist. However, even if, we can simply look for the mangled names of the new runtime once we switched over rather than some `__kmpc` names.
> > We use these in `OpenMPOpt` and `CGOpenMPRuntimeGPU`, could we replace the definitions in `OMPKinds.def` with the mangled names?
> The _kmpc prefix is used for the rest of the functions clang emits calls to, not that keen to replace all those with mangled symbols written in clang
We also (plan to) use these function calls to replace the emission of intrinsics directly from front end, aka those functions in `CGOpenMPRuntimeGPUAMDGCN` and `CGOpenMPRuntimeGPUNVPTX`.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D112154