-
Notifications
You must be signed in to change notification settings - Fork 793
[SYCL][Offload] Add SYCLBIN format and dump tool #16873
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Changes from all commits
1b9f3a1
43c6227
86e3128
1685f0f
a024f11
716bdab
d07b06c
b598b66
a4324ab
be91678
a3b6bf5
b01db8f
224db51
da26032
c5b5060
e7075bb
e74fc36
7c5b050
4197187
9ef58cd
0cc7ba7
2fb9071
159428e
e58061e
c280427
799dcc6
84b619f
498779e
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -236,3 +236,8 @@ def sycl_dump_device_code_EQ : Joined<["--", "-"], "sycl-dump-device-code=">, | |
def sycl_allow_device_image_dependencies : Flag<["--", "-"], "sycl-allow-device-image-dependencies">, | ||
Flags<[WrapperOnlyOption, HelpHidden]>, | ||
HelpText<"Allow dependencies between device code images">; | ||
|
||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I am not sure that this is the best design. @asudarsa @mdtoguchi Do you have any thoughts about this? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Anything in particular you dislike? Ping @asudarsa & @mdtoguchi for their thoughts. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Is this more of an issue with using There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. @asudarsa & @maksimsab - I imagine you know the future plans of the SYCL integration in the clang-linker-wrapper better than I do. What would be the better design here? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I don't have the idea of the whole pipeline with There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I have a major refactoring of clang-linker-wrapper coming up. That should simplify things and help to add this support in a more streamlined way. Thanks There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. From my offline discussion with @asudarsa, it sounds like this would be a stopgap solution either way, as much of the SYCL linker wrapper is being moved anyway. I think it makes sense to discuss the integration of SYCLBIN in our tooling, but if it's going to look vastly different it may be a topic for then. From a user perspective, it shouldn't have any difference before and after. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I had a look at the SYCLBin pipeline and it seems like something that can be easily integrated into the 'new' pipeline where most of the SYCL based compilation flow happens inside a new tool 'clang-sycl-linker. Unfortunately, the new flow is only available upstream and we need a few more changes before syncing it with downstream compiler. Long story short, this PR can be merged as is with the caveat that there will be some modifications required whenever we sync with upstream compiler. Thanks |
||
// Options to force the output to be of the SYCLBIN format. | ||
def syclbin : Flag<["--", "-"], "syclbin">, | ||
Flags<[WrapperOnlyOption]>, | ||
HelpText<"Output in the SYCLBIN binary format">; |
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -47,6 +47,7 @@ enum ImageKind : uint16_t { | |
IMG_Cubin, | ||
IMG_Fatbinary, | ||
IMG_PTX, | ||
IMG_SYCLBIN, | ||
IMG_LAST, | ||
}; | ||
|
||
|
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,148 @@ | ||
//===- SYCLBIN.h - SYCLBIN binary format support ----------------*- C++ -*-===// | ||
// | ||
// Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions. | ||
// See https://llvm.org/LICENSE.txt for license information. | ||
// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception | ||
// | ||
//===----------------------------------------------------------------------===// | ||
|
||
#ifndef LLVM_OBJECT_SYCLBIN_H | ||
#define LLVM_OBJECT_SYCLBIN_H | ||
|
||
#include "llvm/ADT/SmallString.h" | ||
#include "llvm/SYCLPostLink/ModuleSplitter.h" | ||
#include "llvm/Support/MemoryBuffer.h" | ||
#include <string> | ||
|
||
namespace llvm { | ||
|
||
namespace object { | ||
|
||
// Representation of a SYCLBIN binary object. This is intended for use as an | ||
// image inside a OffloadBinary. | ||
class SYCLBIN { | ||
maksimsab marked this conversation as resolved.
Show resolved
Hide resolved
|
||
public: | ||
SYCLBIN(MemoryBufferRef Source) : Data{Source} {} | ||
|
||
SYCLBIN(const SYCLBIN &Other) = delete; | ||
steffenlarsen marked this conversation as resolved.
Show resolved
Hide resolved
|
||
SYCLBIN(SYCLBIN &&Other) = default; | ||
|
||
SYCLBIN &operator=(const SYCLBIN &Other) = delete; | ||
SYCLBIN &operator=(SYCLBIN &&Other) = default; | ||
|
||
MemoryBufferRef getMemoryBufferRef() const { return Data; } | ||
|
||
enum class BundleState : uint8_t { Input = 0, Object = 1, Executable = 2 }; | ||
|
||
struct SYCLBINModuleDesc { | ||
std::string ArchString; | ||
std::vector<module_split::SplitModule> SplitModules; | ||
}; | ||
|
||
class SYCLBINDesc { | ||
public: | ||
SYCLBINDesc(BundleState State, ArrayRef<SYCLBINModuleDesc> ModuleDescs); | ||
|
||
SYCLBINDesc(const SYCLBINDesc &Other) = delete; | ||
SYCLBINDesc(SYCLBINDesc &&Other) = default; | ||
|
||
SYCLBINDesc &operator=(const SYCLBINDesc &Other) = delete; | ||
SYCLBINDesc &operator=(SYCLBINDesc &&Other) = default; | ||
|
||
size_t getMetadataTableByteSize() const; | ||
Expected<size_t> getBinaryTableByteSize() const; | ||
Expected<size_t> getSYCLBINByteSite() const; | ||
|
||
private: | ||
struct ImageDesc { | ||
SmallString<0> Metadata; | ||
SmallString<0> FilePath; | ||
}; | ||
|
||
struct AbstractModuleDesc { | ||
SmallString<0> Metadata; | ||
SmallVector<ImageDesc, 4> IRModuleDescs; | ||
SmallVector<ImageDesc, 4> NativeDeviceCodeImageDescs; | ||
}; | ||
|
||
SmallString<0> GlobalMetadata; | ||
SmallVector<AbstractModuleDesc, 4> AbstractModuleDescs; | ||
|
||
friend class SYCLBIN; | ||
}; | ||
|
||
/// The current version of the binary used for backwards compatibility. | ||
static constexpr uint32_t CurrentVersion = 1; | ||
|
||
/// Magic number used to identify SYCLBIN files. | ||
static constexpr uint32_t MagicNumber = 0x53594249; | ||
|
||
/// Serialize \p Desc to \p OS . | ||
static Error write(const SYCLBIN::SYCLBINDesc &Desc, raw_ostream &OS); | ||
|
||
/// Deserialize the contents of \p Source to produce a SYCLBIN object. | ||
static Expected<std::unique_ptr<SYCLBIN>> read(MemoryBufferRef Source); | ||
|
||
struct IRModule { | ||
std::unique_ptr<llvm::util::PropertySetRegistry> Metadata; | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. should we call these There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I prefer the name "metadata" in this case, as it should only really include the metadata property set for IR modules. You could argue that abstract modules shouldn't have its data named "metadata", but I think for consistency between the levels of modules/images it makes sense to call it metadata. Metadata is also the terminology used in the design document and they all live in the same "metadata byte table", so mixing the terminology might make that concept confusing too. |
||
StringRef RawIRBytes; | ||
}; | ||
struct NativeDeviceCodeImage { | ||
std::unique_ptr<llvm::util::PropertySetRegistry> Metadata; | ||
StringRef RawDeviceCodeImageBytes; | ||
}; | ||
|
||
struct AbstractModule { | ||
std::unique_ptr<llvm::util::PropertySetRegistry> Metadata; | ||
SmallVector<IRModule> IRModules; | ||
SmallVector<NativeDeviceCodeImage> NativeDeviceCodeImages; | ||
}; | ||
|
||
uint32_t Version; | ||
std::unique_ptr<llvm::util::PropertySetRegistry> GlobalMetadata; | ||
SmallVector<AbstractModule, 4> AbstractModules; | ||
|
||
private: | ||
MemoryBufferRef Data; | ||
|
||
struct alignas(8) FileHeaderType { | ||
uint32_t Magic; | ||
uint32_t Version; | ||
uint32_t AbstractModuleCount; | ||
uint32_t IRModuleCount; | ||
uint32_t NativeDeviceCodeImageCount; | ||
uint64_t MetadataByteTableSize; | ||
uint64_t BinaryByteTableSize; | ||
uint64_t GlobalMetadataOffset; | ||
uint64_t GlobalMetadataSize; | ||
}; | ||
|
||
struct alignas(8) AbstractModuleHeaderType { | ||
uint64_t MetadataOffset; | ||
uint64_t MetadataSize; | ||
uint32_t IRModuleCount; | ||
uint32_t IRModuleOffset; | ||
uint32_t NativeDeviceCodeImageCount; | ||
uint32_t NativeDeviceCodeImageOffset; | ||
}; | ||
|
||
struct alignas(8) IRModuleHeaderType { | ||
uint64_t MetadataOffset; | ||
uint64_t MetadataSize; | ||
uint64_t RawIRBytesOffset; | ||
uint64_t RawIRBytesSize; | ||
}; | ||
|
||
struct alignas(8) NativeDeviceCodeImageHeaderType { | ||
uint64_t MetadataOffset; | ||
uint64_t MetadataSize; | ||
uint64_t BinaryBytesOffset; | ||
uint64_t BinaryBytesSize; | ||
}; | ||
}; | ||
|
||
} // namespace object | ||
|
||
} // namespace llvm | ||
|
||
#endif |
Uh oh!
There was an error while loading. Please reload this page.