-
Notifications
You must be signed in to change notification settings - Fork 753
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
Add clang-offload-deps tool for generating dependence files for offload targets #2872
Add clang-offload-deps tool for generating dependence files for offload targets #2872
Conversation
…ad targets This tool is intended to be used by the clang driver for offload linking with static offload libraries. It takes linked host image as input and produces bitcode files (one per offload target) containing references to symbols that must be defined in the target images. Each dependence bitcode file then is expected to be compiled to an object by the driver using appropriate target toolchain, and dependence object added to the target linker as input together with the other inputs. References to the symbols in dependence object should ensure that target linker pulls in necessary symbol definitions from the input static libraries. Signed-off-by: Sergey Dmitriev <serguei.n.dmitriev@intel.com>
static cl::OptionCategory | ||
ClangOffloadDepsCategory("clang-offload-deps options"); | ||
|
||
static cl::list<std::string> Outputs("outputs", cl::CommaSeparated, |
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.
Usually multiple outputs within the driver are handled either via file lists (TY_Tempfilelist) or file tables (TY_Tempfiletable). Driver implementation would easier and more inline with other multi-output tools if this tool could generate a file list listing all the outputs separated by \n.
@mdtoguchi - what do you think?
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.
This interface is consistent with other clang-offload tools.
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 would expect that the outputs match the targets, which is in-line with the bundler. I'm OK with how things are.
ConstantArray::get(ArrayTy, Used), "llvm.used"); | ||
GV->setSection("llvm.metadata"); | ||
} else { | ||
auto *GV = new GlobalVariable( |
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 think from code maintenance perspective it is better to have single mechanism for SPIRV and non-SPIRV. Will the second work for SPIRV target as well? If yes, can the first one be discarded?
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.
Well, LLVM IR just allows to create a reference without adding any additional symbols, I do not see why we should not use this feature. I would rather discard the second part if we had a way to add a reference without adding extra symbols, but looks like this is the only way to do it.
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.
AFAIU, both achieve the same result - letting linker know the deps - and only the second can handle all targets. Hence my suggestion. This is a nit anyway.
@AlexeySachkov, FYI. |
@sndmitriev, please, add yourself as a code owner for this tool to https://github.com/intel/llvm/blob/sycl/.github/CODEOWNERS. |
Signed-off-by: Sergey Dmitriev <serguei.n.dmitriev@intel.com>
@@ -280,6 +280,7 @@ add_custom_target( sycl-toolchain | |||
clang | |||
clang-offload-wrapper | |||
clang-offload-bundler | |||
clang-offload-deps |
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 think we should add this tool to sycl-toolchain
, but if I understand it correctly, the tool is not integrated into compilation flow yet.
I suggest we add it here once the driver make use of it.
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.
Yes, this tool is not integrated into the compilation flow yet.
static cl::OptionCategory | ||
ClangOffloadDepsCategory("clang-offload-deps options"); | ||
|
||
static cl::list<std::string> Outputs("outputs", cl::CommaSeparated, |
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 would expect that the outputs match the targets, which is in-line with the bundler. I'm OK with how things are.
Co-authored-by: mdtoguchi <47896532+mdtoguchi@users.noreply.github.com>
Done |
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.
Thanks!
Does this patch need any additional changes to be merged? |
@sndmitriev There is merge conflict in .github/CODEOWNERS, could you please resolve it? |
90868d3
Done. |
I have resolved conflict. Does this change need anything else to be merged? |
Github UI says: |
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.
LGTM
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.
This tool is intended to be used by the clang driver for offload linking with
static offload libraries. It takes linked host image as input and produces
bitcode files (one per offload target) containing references to symbols that
must be defined in the target images. Each dependence bitcode file then is
expected to be compiled to an object by the driver using appropriate target
toolchain, and dependence object added to the target linker as input together
with the other inputs. References to the symbols in dependence object should
ensure that target linker pulls in necessary symbol definitions from the input
static libraries.
Signed-off-by: Sergey Dmitriev serguei.n.dmitriev@intel.com