Skip to content
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

Merged
merged 5 commits into from
Dec 21, 2020

Conversation

sndmitriev
Copy link
Contributor

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

…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,
Copy link
Contributor

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?

Copy link
Contributor Author

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.

Copy link
Contributor

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.

clang/tools/clang-offload-deps/ClangOffloadDeps.cpp Outdated Show resolved Hide resolved
ConstantArray::get(ArrayTy, Used), "llvm.used");
GV->setSection("llvm.metadata");
} else {
auto *GV = new GlobalVariable(
Copy link
Contributor

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?

Copy link
Contributor Author

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.

Copy link
Contributor

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.

@bader
Copy link
Contributor

bader commented Dec 8, 2020

@AlexeySachkov, FYI.

@bader
Copy link
Contributor

bader commented Dec 8, 2020

@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>
clang/test/Driver/clang-offload-deps.c Outdated Show resolved Hide resolved
@@ -280,6 +280,7 @@ add_custom_target( sycl-toolchain
clang
clang-offload-wrapper
clang-offload-bundler
clang-offload-deps
Copy link
Contributor

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.

Copy link
Contributor Author

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.

clang/tools/clang-offload-deps/ClangOffloadDeps.cpp Outdated Show resolved Hide resolved
static cl::OptionCategory
ClangOffloadDepsCategory("clang-offload-deps options");

static cl::list<std::string> Outputs("outputs", cl::CommaSeparated,
Copy link
Contributor

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.

clang/tools/clang-offload-deps/ClangOffloadDeps.cpp Outdated Show resolved Hide resolved
Co-authored-by: mdtoguchi <47896532+mdtoguchi@users.noreply.github.com>
@sndmitriev
Copy link
Contributor Author

sndmitriev commented Dec 9, 2020

@sndmitriev, please, add yourself as a code owner for this tool to https://github.com/intel/llvm/blob/sycl/.github/CODEOWNERS.

Done

bader
bader previously approved these changes Dec 9, 2020
Copy link
Contributor

@bader bader left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks!

kbobrovs
kbobrovs previously approved these changes Dec 10, 2020
romanovvlad
romanovvlad previously approved these changes Dec 10, 2020
@sndmitriev
Copy link
Contributor Author

Does this patch need any additional changes to be merged?

@romanovvlad
Copy link
Contributor

@sndmitriev There is merge conflict in .github/CODEOWNERS, could you please resolve it?

@sndmitriev sndmitriev dismissed stale reviews from romanovvlad, kbobrovs, and bader via 90868d3 December 17, 2020 13:06
@sndmitriev
Copy link
Contributor Author

@sndmitriev There is merge conflict in .github/CODEOWNERS, could you please resolve it?

Done.

@sndmitriev
Copy link
Contributor Author

I have resolved conflict. Does this change need anything else to be merged?

@romanovvlad
Copy link
Contributor

I have resolved conflict. Does this change need anything else to be merged?

Github UI says:
Waiting on code owner review from intel/llvm-reviewers-runtime, AGindinson, mdtoguchi, elizabethandrews, Fznamznon, and/or premanandrao.

Copy link
Contributor

@mdtoguchi mdtoguchi left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

Copy link
Contributor

@elizabethandrews elizabethandrews left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The patch looks ok to me but I am unfamiliar with this and so I don’t think I’m the right person to review this. @kbobrovs @bader could you please take a look?

@pvchupin pvchupin merged commit 94d2158 into intel:sycl Dec 21, 2020
@sndmitriev sndmitriev deleted the public/sndmitriev/clang-offload-deps branch January 4, 2021 04:01
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

7 participants