-
Notifications
You must be signed in to change notification settings - Fork 796
[SYCL] Refactor SYCL Post Link Library #15365
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 2 commits
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 |
|---|---|---|
|
|
@@ -50,6 +50,8 @@ enum IRSplitMode { | |
| // returned. | ||
| std::optional<IRSplitMode> convertStringToSplitMode(StringRef S); | ||
|
|
||
| StringRef convertSplitModeToString(IRSplitMode SM); | ||
|
|
||
| // A vector that contains all entry point functions in a split module. | ||
| using EntryPointSet = SetVector<Function *>; | ||
|
|
||
|
|
@@ -289,35 +291,41 @@ void dumpEntryPoints(const Module &M, bool OnlyKernelsAreEntryPoints = false, | |
| const char *Msg = "", int Tab = 0); | ||
| #endif // NDEBUG | ||
|
|
||
| struct SplitModule { | ||
| struct ProcessedModule { | ||
| std::string ModuleFilePath; | ||
| util::PropertySetRegistry Properties; | ||
| std::string Symbols; | ||
|
|
||
| SplitModule() = default; | ||
| SplitModule(const SplitModule &) = default; | ||
| SplitModule &operator=(const SplitModule &) = default; | ||
| SplitModule(SplitModule &&) = default; | ||
| SplitModule &operator=(SplitModule &&) = default; | ||
| ProcessedModule() = default; | ||
| ProcessedModule(const ProcessedModule &) = default; | ||
| ProcessedModule &operator=(const ProcessedModule &) = default; | ||
| ProcessedModule(ProcessedModule &&) = default; | ||
| ProcessedModule &operator=(ProcessedModule &&) = default; | ||
|
|
||
| SplitModule(std::string_view File, util::PropertySetRegistry Properties, | ||
| std::string Symbols) | ||
| ProcessedModule(std::string_view File, util::PropertySetRegistry Properties, | ||
| std::string Symbols) | ||
| : ModuleFilePath(File), Properties(std::move(Properties)), | ||
| Symbols(std::move(Symbols)) {} | ||
| }; | ||
|
|
||
| struct ModuleSplitterSettings { | ||
| struct ModuleProcessingSettings { | ||
| IRSplitMode Mode; | ||
| bool OutputAssembly = false; // Bitcode or LLVM IR. | ||
| StringRef OutputPrefix; | ||
| }; | ||
|
|
||
| /// Parses the output table file from sycl-post-link tool. | ||
| Expected<std::vector<SplitModule>> parseSplitModulesFromFile(StringRef File); | ||
| SmallString<64> | ||
| convertProcessingSettingsToString(const ModuleProcessingSettings &S); | ||
|
|
||
| /// Splits the given module \p M according to the given \p Settings. | ||
| Expected<std::vector<SplitModule>> | ||
| splitSYCLModule(std::unique_ptr<Module> M, ModuleSplitterSettings Settings); | ||
| /// Parses the output table file from sycl-post-link tool. | ||
| Expected<std::vector<ProcessedModule>> | ||
| parseProcessedModulesFromFile(StringRef File); | ||
|
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 thought we wanted to seperate module splitting out into a seperate operation, possibly so that we could hook it into any upstream splitting api, but it seems like here we are generalizing these APIs, at least in the name (also, the file name still has split it in which is a little confusing) what's the long term plan/architecture? 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. The following processing pipeline comes only from perspectives of RAM usage and compilation time. It is known that keeping split modules in the RAM is not really possible. It leads to the question where we should perform the spec const and ESIMD parts? Before saving to disk or after? We could do the following scheme: The original scheme takes its roots from the usage of SPIRVTranslator. In case of usage of SPIRV backend it would be much easier like the following: I see your concerns that you need some API for thin-LTO. I was considering to come up with a splitting Pass similar to one that AMD have in llvm-project. While SPIRVTranslator is the main tool you still need to handle spec constants and ESIMD somewhere in thin-LTO. Most likely, 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. thanks for the explanation. actually for thin-lto we call sycl-post-link early (in -c phase) and the processing happens as usual there. running the processing early seems to be enough for everything besides spec constants (that we know of right now), so that one i will do as part of device link, so i don't think there is a need for an API to call all sycl-post-link post-split processing for thinlto, at least not at the moment |
||
|
|
||
| /// Performs post-link processing of the given module \p M according to the | ||
| /// given \p Settings. | ||
| Expected<std::vector<ProcessedModule>> | ||
| SYCLPostLinkProcess(std::unique_ptr<Module> M, | ||
| ModuleProcessingSettings Settings); | ||
|
|
||
| bool isESIMDFunction(const Function &F); | ||
| bool canBeImportedFunction(const Function &F); | ||
|
|
||
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't think "Post Link" is a good choice of wording here. This name reflects some requirements for using this library in compilation process, but I think they are false in general.
For example, in
no-rdcmode, there is no "link" step as the code is self-contained by definition.I think something like "SYCL offload finalization library" better reflects the purpose of this code.
Same applies to
SYCLPostLinkProcessfunction from llvm/include/llvm/SYCLLowerIR/ModuleSplitter.h.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
SYCLOffloadFinalize?There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
In fact, in
no-rdcmode this processing can be done in-cphase because they are already implemented as transformation passes. In that case, there is no need to invoke this library at all inclang-linker-wrapper.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Friendly ping, @bader
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Friendly pong.
Could you clarify what are you trying to ask here?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do you think that
SYCLPostLinkProcessis better to be replaced bySYCLOffloadFinalize?What do you think about my comment regarding
no-rdc?There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
SYCLOffloadFinalizedoesn't seem to fit perfectly, but it sounds better thanSYCLPostLinkProcessin my opinion.I agree, but I don't get the motivation to have a separate "library". Correct me if I wrong, but all this library does is running LLVM passes. My understanding is that we can integrate these LLVM passes either into standard optimization pipeline (preferred) or by building a separate optimization pipeline. @sarnex is using this kind of approach in https://github.com/intel/llvm/pull/15083/files#diff-f7dc51acede945c7c8481147e773e9c09230a93b937bee9eab08ee52826cfa8eR1779.
Basically, I would consider integrating new passes into LLVM optimization pipeline for both
rdcandno-rdcmodes.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Module splitting can't be integrated into
-cphase even if it were be implemented as a Pass.Eventually, I see the compilation pipeline as thin-LTO + optimization pipeline. But I don't see that it happens soon. The plan is to move
sycl-post-linkfunctionality inclang-linker-wrapper. Then move to the thin-LTO once it is ready.