This is an archive of the discontinued LLVM Phabricator instance.

[openmp][devicertl] Freestanding nvptx via stub printf
ClosedPublic

Authored by JonChesterfield on Aug 18 2021, 7:55 PM.

Details

Summary

Compiled nvptx devicertl as freestanding, breaking the
dependency on host glibc and gcc-multilibs. Thus build it by default.

Comes at the cost of #defining out printf. Tried mapping it onto
__builtin_printf but that gets transformed back to printf instead
of hitting the cuda/openmp lowering transform.

Printf could be preserved by one of:

  • dropping all the standard headers and ffreestanding
  • providing a header only printf implementation
  • changing the compiler handling of printf

Diff Detail

Event Timeline

JonChesterfield requested review of this revision.Aug 18 2021, 7:55 PM
Herald added a project: Restricted Project. · View Herald TranscriptAug 18 2021, 7:55 PM
openmp/libomptarget/deviceRTLs/nvptx/src/target_impl.h
83

If we accept this approach, can subsequently delete the code paths around the now-dead printf. Or can leave this here as a vestigial debugging hook.

grokos added inline comments.Aug 19 2021, 2:55 AM
openmp/libomptarget/deviceRTLs/nvptx/CMakeLists.txt
12–13

Change the comment, "by default we will build"

  • update comment
JonChesterfield marked an inline comment as done.Aug 19 2021, 4:00 AM

I'm fine with this, @grokos ?

grokos accepted this revision.Aug 23 2021, 12:53 PM

LGTM too.

This revision is now accepted and ready to land.Aug 23 2021, 12:53 PM
ye-luo added a comment.EditedAug 23 2021, 1:38 PM

How soon will I be able to use printf? I feel loosing printf is a huge negative impact.

Do you use printf in the deviceRTL? Whether it exists in applications is orthogonal to this

Do you use printf in the deviceRTL? Whether it exists in applications is orthogonal to this

I don't. Does this affect using printf in the user offload region? 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.

FWIW, I don't think this will introduce problems. If I'm wrong, we need to identify and resolve them rather than relying on gcc-multilib or something similar.

JonChesterfield added a comment.EditedAug 23 2021, 2:39 PM

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)

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 gcc-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 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.

FWIW, I don't think this will introduce problems. If I'm wrong, we need to identify and resolve them rather than relying on gcc-multilib or something similar.

Cool. I frequently use printf for debugging and will report if it becomes an issue after landing the patch.

@JonChesterfield thank you for the clarification.

Cool. I frequently use printf for debugging

Right there with you :(

and will report if it becomes an issue after landing the patch.

Thanks!