This PR is one of the many PRs in the SYCL upstreaming effort focusing
on device code linking during the SYCL offload compilation process. RFC:
https://discourse.llvm.org/t/rfc-offloading-design-for-sycl-offload-kind-and-spir-targets/74088
In this PR, we introduce a new tool that will be used to perform device
code linking for SYCL offload kind. It accepts SYCL device objects in
LLVM IR bitcode format and will generate a fully linked device object
that can then be wrapped and linked into the host object.
A primary use case for this tool is to perform device code linking for
objects with SYCL offload kind inside the clang-linker-wrapper. It can
also be invoked via clang driver as follows:
`clang --target=spirv64 --sycl-link input.bc`
Device code linking for SYCL offloading kind has a number of known
quirks that makes it difficult to use in a unified offloading setting.
Two of the primary issues are:
1. Several finalization steps are required to be run on the fully-linked
LLVM IR bitcode to gaurantee conformance to SYCL standards. This step is
unique to SYCL offloading compilation flow.
2. SPIR-V LLVM Translator tool is an extenal tool and hence SPIR-V IR
code generation cannot be done as part of LTO. This limitation will be
lifted once SPIR-V backend is available as a viable LLVM backend.
Hence, we introduce this new tool to provide a clean wrapper to perform
SYCL device linking.
Co-Author: Michael Toguchi
Thanks
---------
Signed-off-by: Arvind Sudarsanam <arvind.sudarsanam@intel.com>
This patch fixes:
clang/tools/clang-linker-wrapper/ClangLinkerWrapper.cpp:221:23:
error: unused function 'getInputBitcodeLibrary'
[-Werror,-Wunused-function]
Summary:
These flags were used in the very early days while we were trying to
port stuff. Now that we just pass bitcode to the device link job it
can be easily replaced by `-Xoffload-linker foo.bc`.
The trampoline script used on Windows (due to the absence of shebang
support) doesn't properly expand the path to the Python script, as it
leaves out the drive letter.
Functionally equivalent reproducer in action
```
PS C:\Users\mate> gc (gcm git-clang-formatish.bat).Source
@ECHO OFF
echo "%~pn0" %*
PS C:\Users\mate> git-clang-formatish
"\Users\mate\git-clang-formatish"
```
Adding `d` to the variable modifiers [as per the
docs](https://learn.microsoft.com/en-us/windows-server/administration/windows-commands/for)
the drive letter is added. Even in the magical cases when it works.
(I couldn't reproduce, but I suspect it's only tested from some
bash/cygwin variant, where the path becomes `/c/Program Files/...`, but
the drive letter is needed. Without it, I also observed cases when used
via `git clang-format` (without the inital dash) it tries to infer the
drive letter based on the current working directory. In that case it
fails to find `D:\Program Files\LLVM\bin\clang-format.exe`, which
naturally fails, because `Program Files` is on `C:`)
This patch fixes:
clang/tools/clang-linker-wrapper/ClangLinkerWrapper.cpp:642:6:
error: unused function 'diagnosticHandler'
[-Werror,-Wunused-function]
Summary:
This flag is pretty canonical in ELF linkers, it allows us to force the
link job to extract a library if it defines a specific symbol. This is
mostly useful for letting us forcibly extract things that don't fit the
normal model (i.e. kernels) from static libraries.
Summary:
This should be the linker's job if the user creates any bitcode files,
then passing `-flto` to the linker for the toolchain should be able to
handle it. Right now this path is only used in the case where someone
does LTO w/ ld.gold targeting a CPU so I think we are safe here as that
will still be forwarded, for bfd it'll be an error as it would on the
host. I think I talked the SYCL team out of using this as well so I
should be good to delete it.
This patch adds the number of executed instructions into the timing
output, which provides more stable results compared to wall or process
time.
The format itself is also tweaked so that it's more amenable for direct
import into a spreadsheet editor.
In clang-linker-wrapper, we do not explicitly check if --linker-path is
provided.
This PR adds a check to capture this.
Thanks
---------
Signed-off-by: Arvind Sudarsanam <arvind.sudarsanam@intel.com>
The Intel C++ Compiler (ICX) passes linker flags through the driver
unlike MSVC and clang-cl, and therefore needs them to be prefixed with
`/Qoption,link` (the equivalent of -Wl, for gcc on *nix).
Use the `LINKER:` prefix for the `/EXPORT:` options in clang-repl, this
expands to the correct flag for ICX and nothing for MSVC / clang-cl.
RFC:
https://discourse.llvm.org/t/rfc-cmake-linker-flags-need-wl-equivalent-for-intel-c-icx-on-windows/82446
Add an minor mode which can be optionally used to run clang-format on
save.
Formatting before saving works well and is convenient to avoid having to
remember to manually run clang format.
I've written this as it's own package but it's probably better if the
functionality is supported by clang-format.el.
See: https://github.com/melpa/melpa/pull/8762
Line ending policies were changed in the parent, dccebddb3b80. To make
it easier to resolve downstream merge conflicts after line-ending
policies are adjusted this is a separate whitespace-only commit. If you
have merge conflicts as a result, you can simply `git add --renormalize
-u && git merge --continue` or `git add --renormalize -u && git rebase
--continue` - depending on your workflow.
The 'vector' clause specifies the iterations to be executed in vector or
SIMD mode. There are some limitations on which associated compute
contexts may be associated with this and have arguments, but otherwise
this is a fairly unrestricted clause.
It DOES have region limits like 'gang' and 'worker'.
The worker clause specifies iterations of the loop/ that are executed in
parallel by distributing the iterations among the multiple works within
a single gang.
The sema rules for this type are simply that it cannot be combined with
a `kernel` construct with a `num_workers` clause, child `loop` clauses
cannot contain a `gang` or `worker` clause, and that the argument is oly
allowed when associated with a `kernel`.
This is part of the effort to support for enabling plugins on windows by
adding better support for building llvm and clang as a DLL. These macros
are similar to the ones i added in #96630, but are for clang.
Added explicit symbol visibility macros definitions that are defined in
a new header and will be used to for shared library builds of clang to
export
symbols.
Updated clang cmake to define a macro to enable the symbol visibility
macros and explicitly disable them for clang tools that always use
static linking.
---------
Co-authored-by: Aaron Ballman <aaron@aaronballman.com>
The 'gang' clause is used to specify parallel execution of loops, thus
has some complicated rules depending on the 'loop's associated compute
construct. This patch implements all of those.
The dependency scanner uses the `llvm::json` library for outputting the
dependency information. Until now, it created an in-memory
representation of the dependency graph using the `llvm::json::Object`
hierarchy. This not only creates unnecessary copies of the data, but
also forces lexicographical ordering of attributes in the output, both
of which I'd like to avoid. This patch adopts the `llvm::json::OStream`
API instead and reorders the attribute printing logic such that the
existing lexicographical ordering is preserved (for now).
Add the permutation clause for the interchange directive which will be
introduced in the upcoming OpenMP 6.0 specification. A preview has been
published in
[Technical Report12](https://www.openmp.org/wp-content/uploads/openmp-TR12.pdf).
The 'tile' clause shares quite a bit of the rules with 'collapse', so a
followup patch will add those tests/behaviors. This patch deals with
adding the AST node.
The 'tile' clause takes a series of integer constant expressions, or *.
The asterisk is now represented by a new OpenACCAsteriskSizeExpr node,
else this clause is very similar to others.
The 'collapse' clause on a 'loop' construct is used to specify how many
nested loops are associated with the 'loop' construct. It takes an
optional 'force' tag, and an integer constant expression as arguments.
There are many other restrictions based on the contents of the loop/etc,
but those are implemented in followup patches, for now, this patch just
adds the AST node and does basic argument checking on the loop-count.
Summary:
This was intended to be a neat optimization, but some objects come from
archives so this won't work. I could write some code to detect if it
came from an archive but I don't think it's wroth the complexity when
this already doesn't work on Windows.
Summary:
We need all inputs to `nvlink` to end in `.cubin` while the rest of the
compiler toolchain wants `.o`. Previously we copied `.o` file to
`.cubin` files, but this is wasteful. Instead, we can just create a link
against it. This saves some disk space during link time.
This reverts commit e39205654dc11c50bd117e8ccac243a641ebd71f.
There are further discussions in
https://github.com/llvm/llvm-project/pull/70976, happening for past two
weeks. Since there were no responses for couple weeks now, reverting
until author is back.
Some `FileManager` APIs still return `{File,Directory}Entry` instead of
the preferred `{File,Directory}EntryRef`. These are documented to be
deprecated, but don't have the attribute that warns on their usage. This
PR marks them as such with `LLVM_DEPRECATED()` and replaces their usage
with the recommended counterparts. NFCI.
Without this patch, several callers of LoadFromASTFile construct an
instance of std::string to be passed as FileName, only to be converted
back to StringRef when LoadFromASTFile calls ReadAST.
This patch changes the type of FileName to StringRef and updates the
callers.
Enable building clang-cpp shared library for windows when building with
explicit visibility macros enabled and LLVM is built as a shared
library(LLVM_BUILD_LLVM_DYLIB_VIS).
This is part of the effort to support for enabling plugins on windows by
adding better support for building LLVM and Clang as a DLL.
Summary:
Sometimes `clang` will pass `-plugin` when doing LTO, which should be
correctly consumed by the nvlink wrapper. Right now it was leaving the
`plugin.so` argument as a regular input, which would cause it to error
on the `.so` input.
Since a26ec542371652e1d774696e90016fd5b0b1c191, we expand the executable
name to an absolute path, if it isn't already one, if found in path.
This broke a couple tests in some environments; when the clang workdir
resides in a path under e.g. /opt. Tests that only use a tool name like
"clang-cl" would get expanded to the absolute path in the build tree.
The loop for finding the last "-o" like option for clang-cl command
lines would inspect all arguments, including Args[0] which is the
executable name itself. As an /opt path matches Arg.starts_with("/o"),
this would get detected as an object file output name in cases where
there was no other explicit output argument.
Thus, this fixes those tests in workdirs under e.g. /opt.
from PEP8
(https://peps.python.org/pep-0008/#programming-recommendations):
> Comparisons to singletons like None should always be done with is or
is not, never the equality operators.
Co-authored-by: Eisuke Kawashima <e-kwsm@users.noreply.github.com>
clang-rename has largely been superseded by clangd and this project
hasn't received much attention in many years. Further, our
documentation on it still claims it's in very early stages of
development despite being ~10 years old. One of the primary people
driving the tool has mentioned that they don't believe there is a
reason to continue to support it unless it's still being actively
used (https://reviews.llvm.org/D148439#4303202) and I've found no
evidence to suggest that is the case.
Original RFC:
https://discourse.llvm.org/t/rfc-time-to-deprecate-remove-clang-rename/70707
This reverts commit e7f782e7481cea23ef452a75607d3d61f5bd0d22.
This had UBSan failures:
[----------] 1 test from ConfigCompileTests
[ RUN ] ConfigCompileTests.DiagnosticSuppression
Config fragment: compiling <unknown>:0 -> 0x00007B8366E2F7D8 (trusted=false)
/usr/local/google/home/fmayer/large/llvm-project/llvm/include/llvm/ADT/IntrusiveRefCntPtr.h:203:33: runtime error: reference binding to null pointer of type 'clang::DiagnosticIDs'
UndefinedBehaviorSanitizer: undefined-behavior /usr/local/google/home/fmayer/large/llvm-project/llvm/include/llvm/ADT/IntrusiveRefCntPtr.h:203:33
Pull Request: https://github.com/llvm/llvm-project/pull/108645
This allows the clang driver to know which tool is meant to be executed,
which allows the clang driver to load the right clang config files, and
allows clang to find colocated sysroots.
This makes sure that doing `clang-scan-deps -- <tool> ...` looks up
things in the same way as if one just would execute `<tool> ...`, when
`<tool>` isn't an absolute or relative path.
