[Openmp-commits] [PATCH] D108349: [openmp][devicertl] Freestanding nvptx via stub printf

[Jon Chesterfield via Phabricator via Openmp-commits]

JonChesterfield added a comment.

In D108349#2961131 <https://reviews.llvm.org/D108349#2961131>, @ye-luo wrote:

> I don't. Does this affect using printf in the user offload region?

No. Printf in user openmp code (provided they didn't compile their own code as freestanding) gets mapped onto cuda printf and behaves identically (iiuc that means no output until the target region returns)

In D108349#2961131 <https://reviews.llvm.org/D108349#2961131>, @ye-luo wrote:

> I need to be sure users still can call printf without hassle.
> if now user code need to figure out glibc and gcc-multilibs dependency when printf is used in the offload region. Then I'm afraid it is worse than libomptarget having this dependency.

Also orthogonal. Users can have a variety of problems using 32 bit nvptx on 64 bit host and the error messages do not make it obvious that they're missing multilibs. They also need to arrange for there to be cuda somewhere and for the toolchain to find it. That seems to be difficult, e.g. I couldn't get clang to find the debian packaged cuda. So I can't say with any confidence that people will have a hassle free experience using printf via nvptx openmp.

However, that capability has no interaction with this patch. This disables drops the printf debugging calls from the runtime itself so that the runtime can build without gcc multilibs, much like a different patch dropped the requirement for cuda to build the host runtime. The end user still needs all the cuda stuff but whoever is building the toolchain, e.g. as part of a linux distribution, won't need it any more.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D108349