This is an archive of the discontinued LLVM Phabricator instance.

[Libomptarget] Build the device library even if the sm list is empty
ClosedPublic

Authored by jhuber6 on Jul 21 2022, 6:35 AM.

Details

Summary

We previously had some logic that stopped us from building the device runtime if
there were no NVPTX architectures provided. This is incorrect because we could
have AMDGPU libraries. Even if the lists are empty we should be able to attempt
to build these and get dummy output. THis wilil make it much easier for our
tooling which expects certain libraries. If the user wishes to disable the
library entirely they should use `-DLIBOMPTARGET_BUILD_DEVICERTL_BCLIB=OFF"

Diff Detail

Event Timeline

jhuber6 created this revision.Jul 21 2022, 6:35 AM
Herald added a project: Restricted Project. · View Herald TranscriptJul 21 2022, 6:35 AM
jhuber6 requested review of this revision.Jul 21 2022, 6:35 AM
Herald added a project: Restricted Project. · View Herald TranscriptJul 21 2022, 6:35 AM
tianshilei1992 added a comment.EditedJul 21 2022, 7:27 AM

Does it affect the option that we can build bc lib for one arch but not for another, like I just would like to build AMD bc lib? We can't assume the LLVM/Clang used for the compilation supports all arch.

Does it affect the option that we can build bc lib for one arch but not for another, like I just would like to build AMD bc lib? We can't assume the LLVM/Clang used for the compilation supports all arch.

If the lists are empty, the for loops setting the architecture won't generate any code right. For the static library it won't get embedded in the binary either.

tianshilei1992 accepted this revision.Jul 21 2022, 7:33 AM

Does it affect the option that we can build bc lib for one arch but not for another, like I just would like to build AMD bc lib? We can't assume the LLVM/Clang used for the compilation supports all arch.

If the lists are empty, the for loops setting the architecture won't generate any code right. For the static library it won't get embedded in the binary either.

Right. The logic here is a little messy because contains some inconsistency when we implemented DeviceRTL first for NVPTX and later for AMDGPU.

This revision is now accepted and ready to land.Jul 21 2022, 7:33 AM
This revision was landed with ongoing or failed builds.Jul 21 2022, 7:58 AM
This revision was automatically updated to reflect the committed changes.