yaxunl added inline comments.
================
Comment at: clang/docs/ClangOffloadBinary.rst:15
+metadata. We use a custom binary format for bundling all the device images
+together. The image format is a small header wrapping around a string map. This
+tool creates bundled binaries so that they can be embedded into the host to
----------------
It would help if more details are given, e.g, offset and size of members of the
header and layout of the string map.
================
Comment at: clang/test/Frontend/embed-object.c:3
-// CHECK: @[[OBJECT:.+]] = private constant [120 x i8] c"\10\FF\10\AD{{.*}}",
section ".llvm.offloading", align 8
+// CHECK: @[[OBJECT:.+]] = private constant [0 x i8] zeroinitializer, section
".llvm.offloading", align 8
// CHECK: @llvm.compiler.used = appending global [1 x ptr] [ptr @[[OBJECT]]],
section "llvm.metadata"
----------------
Is this due to the embedded object being empty?
So now the bitcode for different targets are bundled by clang-offload-packager
then embedded as one file in the relocatable object file?
In the old scheme the bitcode for different targets are bundled by
clang-offload-bundler then embedded in the relocatable object file, right?
What's the advantage of clang-offload-packager compared with
clang-offload-bundler?
Repository:
rG LLVM Github Monorepo
CHANGES SINCE LAST ACTION
https://reviews.llvm.org/D125165/new/
https://reviews.llvm.org/D125165
_______________________________________________
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
