[clang-offload-bundler] Standardize TargetID field for bundler

[lamb-j]

Summary

The bundler accepts both of the following for the --target option:

hip-amdgcn-amd-amdhsa-gfx900    (no ABI field)
hip-amdgcn-amd-amdhsa--gfx900   (blank ABI field)

The env (environment) field is defined as optional for Triples in Triple.h.
However, in this patch we update the bundler to internally
standardize to include the env field. While users aren't required
to specify an environment field when listing targets on the commandline,
bundles generated by the offload-bundler will include the env
field.

This standardization simplifies things for APIs that deal with
bundles generated by the clang-offload-bundler tool.

[yaxunl]

The description needs fix. "ABI field" should be "environment component".

Also, we need a clang-offload-bundler test which bundles with a non-canonical triple and unbundles with a canonical triple and vice versa.

clang/lib/Driver/OffloadBundler.cpp

76–79

can we use Triple::normalize to normalize KindTriple.second, then use the returned string to create this->Triple? This is the conventional way to normalize the triple.

same as below

[lamb-j]

In D145770#4184996, @yaxunl wrote:

The description needs fix. "ABI field" should be "environment component".

Also, we need a clang-offload-bundler test which bundles with a non-canonical triple and unbundles with a canonical triple and vice versa.

I'm not sure if we can use Triple.normalize(). Here's what I got from a small test:

amdgcn-amd-amdhsa  ->  amdgcn-amd-amdhsa (no env field added)
amdgcn-amd-amdhsa- ->  amdgcn-amd-amdhsa-unknown (empty env changed to unknown)

Also are we sure ABI is incorrect? That's what is used here:

https://clang.llvm.org/docs/CrossCompilation.html

(I'm happy to change to environment, just double checking)

[yaxunl]

In D145770#4185658, @lamb-j wrote:

In D145770#4184996, @yaxunl wrote:

The description needs fix. "ABI field" should be "environment component".

Also, we need a clang-offload-bundler test which bundles with a non-canonical triple and unbundles with a canonical triple and vice versa.

I'm not sure if we can use Triple.normalize(). Here's what I got from a small test:

amdgcn-amd-amdhsa  ->  amdgcn-amd-amdhsa (no env field added)
amdgcn-amd-amdhsa- ->  amdgcn-amd-amdhsa-unknown (empty env changed to unknown)

Also are we sure ABI is incorrect? That's what is used here:

https://clang.llvm.org/docs/CrossCompilation.html

(I'm happy to change to environment, just double checking)

https://github.com/llvm/llvm-project/blob/main/llvm/include/llvm/TargetParser/Triple.h only talks about "environment", which seems to be more accurate and up-to-date.

It is unfortunate that we have used our own normalization (empty string for unspecified environment instead of "unknown") for triple. Looks like we have to keep that for now. Ideally, HIP runtime should accept "amdgcn-amd-amdhsa-unknown" in addition to "amdgcn-amd-amdhsa--" in fat binary, then we could switch to the LLVM Triple normalization. But that requires runtime change first. Probably we could do that in future.

[lamb-j]

In D145770#4186142, @yaxunl wrote:

In D145770#4185658, @lamb-j wrote:

In D145770#4184996, @yaxunl wrote:

The description needs fix. "ABI field" should be "environment component".

Also, we need a clang-offload-bundler test which bundles with a non-canonical triple and unbundles with a canonical triple and vice versa.

I'm not sure if we can use Triple.normalize(). Here's what I got from a small test:

amdgcn-amd-amdhsa  ->  amdgcn-amd-amdhsa (no env field added)
amdgcn-amd-amdhsa- ->  amdgcn-amd-amdhsa-unknown (empty env changed to unknown)

Also are we sure ABI is incorrect? That's what is used here:

https://clang.llvm.org/docs/CrossCompilation.html

(I'm happy to change to environment, just double checking)

https://github.com/llvm/llvm-project/blob/main/llvm/include/llvm/TargetParser/Triple.h only talks about "environment", which seems to be more accurate and up-to-date.

It is unfortunate that we have used our own normalization (empty string for unspecified environment instead of "unknown") for triple. Looks like we have to keep that for now. Ideally, HIP runtime should accept "amdgcn-amd-amdhsa-unknown" in addition to "amdgcn-amd-amdhsa--" in fat binary, then we could switch to the LLVM Triple normalization. But that requires runtime change first. Probably we could do that in future.

It may be fine to use "unknown" instead of an empty string, I didn't test that. It's just that the Triple.normalize() doesn't add anything for the env field if there wasn't anything there to begin with. That is, it doesn't convert a 3-field triple to a 4-field triple (it only converts a 4-field with empty string env to 4-field "unknown" env").

And sounds good about abi vs. env, maybe I'll add another patch to update CrossCompilation.html so it's more consistent with Triple.h

[lamb-j]

Adding another test, updating existing large test, and switching from ABI
to env

[lamb-j]

clang/test/Driver/clang-offload-bundler.c

2

Can most systems cross-compile for powerpc? This test does a lot of testing, seems like it would be nice to test it on other systems.

[scott.linder]

Is there a corresponding document update to go along with this? If consumers of the bundles will begin to rely on this it should be documented that it is guaranteed by the producer.

[lamb-j]

Adding note to documentation

[lamb-j]

In D145770#4190901, @scott.linder wrote:

Is there a corresponding document update to go along with this? If consumers of the bundles will begin to rely on this it should be documented that it is guaranteed by the producer.

Good point, documentation udpated

[yaxunl]

LGTM. Please update the description.

[lamb-j]

Updating commit message

[dyung]

@lamb-j the test clang-offload-bundler.c is failing on the PS4 linux builder, can you take a look?

https://lab.llvm.org/buildbot/#/builders/139/builds/37475

I don't know if it matters, but this bot only builds the x86_64 target.

[dyung]

In D145770#4195018, @dyung wrote:

@lamb-j the test clang-offload-bundler.c is failing on the PS4 linux builder, can you take a look?

https://lab.llvm.org/buildbot/#/builders/139/builds/37475

I don't know if it matters, but this bot only builds the x86_64 target.

To unblock our bots, I've marked the test as XFAIL for PS4/PS5 in 768211f48f2d52fdd555a07f3dae8fbf1def88cc, please investigate when you can.

[lamb-j]

Needed to update this after landing with two quick patch fixes:

[clang-offload-bundler] Fix test failures and document typo (65fb636bd462)

[clang-offload-bundler] Fix error with regex in bundler test (f3b991202689)

There were also two quick fixes by others that overlapped but got in before my fixes:

Mark test modified in e48ae0d as XFAIL for PS4/PS5 until the author ... (768211f48f2d)

clang/test/Driver/clang-offload-bundler-standardize.c REQUIRES asserts. (fixup D145770) (d4a4d0d79127)

[mdtoguchi]

@lamb-j - is it expected for any bundled objects created before your change without the explicit env field to be able to be unbundled? Newly generated bundles work as expected given similar -target values, but older generated binaries fail to unbundle the target given equivalent commands. Is it possible to provide the ability to do so?

[yaxunl]

In D145770#4220246, @mdtoguchi wrote:

@lamb-j - is it expected for any bundled objects created before your change without the explicit env field to be able to be unbundled? Newly generated bundles work as expected given similar -target values, but older generated binaries fail to unbundle the target given equivalent commands. Is it possible to provide the ability to do so?

what is the target used by the old bundle? Thanks.

[lamb-j]

In D145770#4220246, @mdtoguchi wrote:

@lamb-j - is it expected for any bundled objects created before your change without the explicit env field to be able to be unbundled? Newly generated bundles work as expected given similar -target values, but older generated binaries fail to unbundle the target given equivalent commands. Is it possible to provide the ability to do so?

That should still be supported. The target triple for the old bundle should be converted to the new format (and compared against the Target-ID that was also converted to the new format). Can you provide an example to recreate the failure? I just tried one example locally and didn't hit any failures:

old-clang -c --offload-arch=gfx906 -emit-llvm -fgpu-rdc --gpu-bundle-output square.hip
new-clang-offload-bundler -unbundle -type=bc -targets=hip-amdgcn-amd-amdhsa-gfx906 -input=square.bc -output=square-hip-gfx906.bc -allow-missing-bundles -debug-only=CodeObjectCompatibility

Compatible: Exact match:        [CodeObject: hip-amdgcn-amd-amdhsa--gfx906]     :       [Target: hip-amdgcn-amd-amdhsa--gfx906]