[Comgr] Add an unpackaging action #668
Conversation
|
Thank you for submitting a Pull Request (PR) to the LLVM Project! This PR will be automatically labeled and the relevant teams will be notified. If you wish to, you can add reviewers by using the "Reviewers" section on this page. If this is not working for you, it is probably because you do not have write permissions for the repository. In which case you can instead tag reviewers by name in a comment by using If you have received no comments on your PR for a week, you can request a review by "ping"ing the PR by adding a comment “Ping”. The common courtesy "ping" rate is once a week. Please remember that you are asking for valuable time from other developers. If you have further questions, they may be answered by the LLVM GitHub User Guide. You can also ask questions in a comment on this PR, on the LLVM Discord or on the forums. |
|
|
||
| /** | ||
| * Unpackage each source data object in @p input. For each successful | ||
| * unbundling, add a bc object or archive object to @p result, depending on |
There was a problem hiding this comment.
| * unbundling, add a bc object or archive object to @p result, depending on | |
| * unpackaging, add a bc object or archive object to @p result, depending on |
Also guessing we should replace "bc object or archive object" with the expected object types from a package
| break; | ||
| } | ||
|
|
||
| for (StringRef Entry : ActionInfo->BundleEntryIDs) { |
There was a problem hiding this comment.
| for (StringRef Entry : ActionInfo->BundleEntryIDs) { | |
| for (StringRef Entry : ActionInfo->PackageEntryIDs) { |
| size_t PackageSize; | ||
|
|
||
| if (argc < 4) { | ||
| printf("Usage: %s <bc bundle> <arch> <bc output>\n", argv[0]); |
There was a problem hiding this comment.
| printf("Usage: %s <bc bundle> <arch> <bc output>\n", argv[0]); | |
| printf("Usage: %s <bc package> <arch> <bc output>\n", argv[0]); |
| case llvm::object::IMG_Object: | ||
| FileExtension = "o"; | ||
| break; | ||
| case llvm::object::IMG_Bitcode: | ||
| FileExtension = "bc"; | ||
| break; | ||
| case llvm::object::IMG_Cubin: | ||
| FileExtension = "cubin"; | ||
| break; | ||
| case llvm::object::IMG_Fatbinary: | ||
| FileExtension = "fatbin"; | ||
| break; | ||
| case llvm::object::IMG_PTX: | ||
| FileExtension = "ptx"; | ||
| break; | ||
| case llvm::object::IMG_SPIRV: | ||
| FileExtension = "spv"; | ||
| break; | ||
| default: | ||
| FileExtension = "unknown"; | ||
| break; |
There was a problem hiding this comment.
Should we ERROR_INVALID_ARGUMENT for unsupported ImageKinds? Cubin/PTX?
There was a problem hiding this comment.
I was thinking that we should imagine ImageKind as a non-exhaustive tag. All image data types are treated the exact same way (basically directly copying the byte data into a file descriptor) and I don't imagine that will need to change at any point, since text data would be treated the same way. I thought a .unknown fallback would be more justifiable than an error because, if it's a well-formed package, it shouldn't matter what type it is. OTOH, if packages do gain some sort of differentiated images in the future, our implementation might unexpectedly break. What do you think makes more sense?
There was a problem hiding this comment.
I'm mostly thinking about it for the return AMD_COMGR_DATA_KIND
But maybe instead of erroring, we could set the output file DATA_KIND to AMD_COMGR_DATA_KIND_UNDEF (for the ImageKinds that don't have a corresponding DATA_KIND)?
There was a problem hiding this comment.
Though looking more, seems like DATA_KIND_UNDEF is used to signal destroyed/invalid data objects, so that probably won't work:
llvm-project/amd/comgr/src/comgr.cpp
Line 312 in 41f7de0
4 participants
Currently, clang uses the
clang-offload-bundlerto offload GPU binaries, but thellvm-offload-binarypackager is a possible replacement for GPU offloading. This PR adds support to Comgr for retrieving the files from anllvm-offload-binarypackage through an Unpackager class and anAMD_COMGR_ACTION_UNPACKAGEaction.