This is an archive of the discontinued LLVM Phabricator instance.

[clang-offload-bundler] extracting compatible bundle entry
ClosedPublic

Authored by yaxunl on Sep 23 2022, 9:09 AM.

Details

Summary

In HIP a library is usually compiled with default target ID e.g. gfx906 so that
it can be used in all GPU configurations. The bitcode is saved in bundled
bitcode with gfx906 in entry ID.

In runtime compilation, a HIP program is compiled with a target ID matching
the GPU configuration, e.g. gfx906:xnack-. This program needs to link with
a library bundled bitcode with target ID gfx906.

For example:

clang --offload-arch=gfx906 -o lib.o lib.hip
clang --offload-arch=gfx906:xnack- program.hip lib.o

This common use case requires that clang-offlod-bundler to be able to extract
entry with compatible target ID, e.g. extracting an gfx906 entry when requesting
gfx906:xnack-.

Currently clang-offload-bundler only allow extracting entry with exact match
of target ID. This patch relaxes that so that it can extract entries with compatible
target ID.

Diff Detail

Event Timeline

yaxunl created this revision.Sep 23 2022, 9:09 AM
Herald added a project: Restricted Project. · View Herald TranscriptSep 23 2022, 9:09 AM
yaxunl requested review of this revision.Sep 23 2022, 9:09 AM
tra added inline comments.Sep 23 2022, 10:42 AM
clang/lib/Driver/OffloadBundler.cpp
1008

The patch description implies that there are at least two classes of compatible objects -- the ones that match exactly and the ones that are not exact match, but are still compatible.

Here we're iterating until we find the first compatible object. What if we also have the object that matches exactly, but it's further down the list. Is that a problem that we may pick one or the other, depending on the order they happen to appear in the worklist? It would be good to add a test case for this scenario.

The patch looks fine to me.
Please wait for @tra 's final review.

On a different note, can this compatibility testing logic be moved to a llvm library instead of clang's?
I want to use it in OpenMP's AMDGPU plugin, which now links llvm libraries by default.

clang/lib/Driver/OffloadBundler.cpp
1008

Though it looks plausible, such a case is not possible.

From Clang Offload Bundler's Documentation

If there is an entry with a target feature specified as Any, then all entries must specify that target feature as Any for the same processor.

tra added inline comments.Sep 23 2022, 11:41 AM
clang/lib/Driver/OffloadBundler.cpp
1008

Does it mean that the bundler is supposed to error out if I pass -targets=hip-amdgcn-amd-amdhsa--gfx906,hip-amdgcn-amd-amdhsa--gfx906:xnack- ?

I've just tried it with a bundler built in recent LLVM tree and it accepts such a mis of targets without complaining.

yaxunl marked 3 inline comments as done.Oct 4 2022, 8:15 PM
yaxunl added inline comments.
clang/lib/Driver/OffloadBundler.cpp
1008

Bundle entries in the same bundle should follow the constraints specified in the clang-offload-bundler documentation.

Currently, clang enforces the rule when specifying --offload-arch options, which is the most common approach to generate the clang-offload-bundler bundles. However, if users use clang-offload-bundler directly to generate the bundle, the rule is not enforced.

I will add the enforcement to clang-offload-bundler too.

yaxunl updated this revision to Diff 465265.Oct 4 2022, 8:24 PM
yaxunl marked an inline comment as done.

check bundle entry ID compatibility when bundling

tra accepted this revision.Oct 5 2022, 10:22 AM
This revision is now accepted and ready to land.Oct 5 2022, 10:22 AM
This revision was landed with ongoing or failed builds.Oct 5 2022, 4:45 PM
This revision was automatically updated to reflect the committed changes.
Herald added a project: Restricted Project. · View Herald TranscriptOct 5 2022, 4:45 PM