This patch uses the existing logic of CUDA for searching libomptarget
and extracts it to a common method.
Reviewed By: JonChesterfield, tianshilei1992
Differential Revision: https://reviews.llvm.org/D96248
Generate outline atomics if compiling for armv8-a non-LSE AArch64 Linux
(including Android) targets to use LSE instructions, if they are available,
at runtime. Library support is checked by clang driver which doesn't enable
outline atomics if no proper libraries (libgcc >= 9.3.1 or compiler-rt) found.
Differential Revision: https://reviews.llvm.org/D93585
From this patch (plus some landed patches), `deviceRTLs` is taken as a regular OpenMP program with just `declare target` regions. In this way, ideally, `deviceRTLs` can be written in OpenMP directly. No CUDA, no HIP anymore. (Well, AMD is still working on getting it work. For now AMDGCN still uses original way to compile) However, some target specific functions are still required, but they're no longer written in target specific language. For example, CUDA parts have all refined by replacing CUDA intrinsic and builtins with LLVM/Clang/NVVM intrinsics.
Here're a list of changes in this patch.
1. For NVPTX, `DEVICE` is defined empty in order to make the common parts still work with AMDGCN. Later once AMDGCN is also available, we will completely remove `DEVICE` or probably some other macros.
2. Shared variable is implemented with OpenMP allocator, which is defined in `allocator.h`. Again, this feature is not available on AMDGCN, so two macros are redefined properly.
3. CUDA header `cuda.h` is dropped in the source code. In order to deal with code difference in various CUDA versions, we build one bitcode library for each supported CUDA version. For each CUDA version, the highest PTX version it supports will be used, just as what we currently use for CUDA compilation.
4. Correspondingly, compiler driver is also updated to support CUDA version encoded in the name of bitcode library. Now the bitcode library for NVPTX is named as `libomptarget-nvptx-cuda_[cuda_version]-sm_[sm_number].bc`, such as `libomptarget-nvptx-cuda_80-sm_20.bc`.
With this change, there are also multiple features to be expected in the near future:
1. CUDA will be completely dropped when compiling OpenMP. By the time, we also build bitcode libraries for all supported SM, multiplied by all supported CUDA version.
2. Atomic operations used in `deviceRTLs` can be replaced by `omp atomic` if OpenMP 5.1 feature is fully supported. For now, the IR generated is totally wrong.
3. Target specific parts will be wrapped into `declare variant` with `isa` selector if it can work properly. No target specific macro is needed anymore.
4. (Maybe more...)
Reviewed By: JonChesterfield
Differential Revision: https://reviews.llvm.org/D94745
We're choosing to take an opt-in approach for landing Relative VTables, so we'll
need asan-equivalent multilibs with relative vtables enabled. Afterwards, we can
just flip the switch in our build.
Differential Revision: https://reviews.llvm.org/D95253
D94700 removed the static library so we no longer need to pass
`-llibomptarget-nvptx` to `nvlink`. Since the bitcode library is the only device
runtime for now, instead of emitting a warning when it is not found, an error
should be raised. We also set a new option `libomptarget-nvptx-bc-path` to let
user choose which bitcode library is being used.
Reviewed By: JonChesterfield
Differential Revision: https://reviews.llvm.org/D95161
- Need trimming before parsing major or minor version numbers. This's required
due to the different line ending on Windows.
- In addition, the integer conversion may fail due to invalid char. Return that
parsing function return `true` when the parsing fails.
Differential Revision: https://reviews.llvm.org/D93587
Optimize toolchain regression test for VE by removing not a useful test
(-fuse-init-array test) and merge several tests to one test which checks
default behavior of driver. Also add sysroot to reduce conflicts.
These are suggested in https://reviews.llvm.org/D92996.
Thank you so much.
Reviewed By: MaskRay
Differential Revision: https://reviews.llvm.org/D93084
This adds multilibs for Fuchsia that is built with the relative vtables ABI,
one with and another without exceptions.
Differential Revision: https://reviews.llvm.org/D85576
The test failed silently if lld wasn't built alongside clang.
But the test uses -###, so the "invalid linker name in -fuse-ld=lld"
diag didn't make clang fail, and something else happened to match
"-demangle", so the test passed.
To fix, pass -B to a directory with two empty +x files (which works
on non-Windows), and look for `"-demangle"` instead of just `-demangle`.
Also force linker_version to 0 and pass a darwin triple.
Differential Revision: https://reviews.llvm.org/D92028
This fixes the Builtins-sparc-linux testsuite failures on Linux
SPARC which occur because clang cannot find the 32-bit runtime
libraries when -m32 is passed on the command line. The same
workaround is already being used on X86 and PPC.
Also, switch the CHECK-DEBIAN-SPARC tests to use debian_multiarch_tree
as both sparc and sparc64 are using the MultiArch mechanism on modern Debian
systems the same way as x86_64, powerpc64el and others. Thus, switch the
CHECK-DEBIAN-SPARC32 and CHECK-DEBIAN-SPARC64 tests to use the files from
the debian_multiarch_tree directory for the header and linker path tests.
Finally, rename CHECK-DEBIAN-SPARC32 to CHECK-DEBIAN-SPARC to match the naming
scheme of the Debian MultiArch checks for the other Debian architectures.
Reviewed By: MaskRay, phosek
Differential Revision: https://reviews.llvm.org/D90524
The test needs an object file, which it currenty gets with
`-target x86_64-apple-darwin10`. Rather than adding `REQUIRES: X86`, create
the object file via yaml2obj. This way, the test runs and passes even if the
host arch isn't x86 and only the host arch is built.
Part of PR46644.
If CUDA version can not be determined based on version.txt file, attempt to find
CUDA_VERSION macro in cuda.h.
This is a follow-up to D89752,
Differntial Revision: https://reviews.llvm.org/D89832
CUDA-11.1 does not carry version.txt which causes clang to assume that it's
CUDA-7.0, which used to be the only CUDA version w/o version.txt.
In order to tell CUDA-7.0 apart from the new versions, clang now probes for the
presence of libdevice.10.bc which is not present in the old CUDA versions.
This should keep Clang working for CUDA-11.1.
PR47332: https://bugs.llvm.org/show_bug.cgi?id=47332
Differential Revision: https://reviews.llvm.org/D89752
Currently, Clang looks for libc++ headers alongside the installation
directory of Clang, and it also adds a search path for headers in the
-isysroot. This is problematic if headers are found in both the toolchain
and in the sysroot, since #include_next will end up finding the libc++
headers in the sysroot instead of the intended system headers.
This patch changes the logic such that if the toolchain contains libc++
headers, no C++ header paths are added in the sysroot. However, if the
toolchain does *not* contain libc++ headers, the sysroot is searched as
usual.
This should not be a breaking change, since any code that previously
relied on some libc++ headers being found in the sysroot suffered from
the #include_next issue described above, which renders any libc++ header
basically useless.
Differential Revision: https://reviews.llvm.org/D89001
Add an option --gpu-instrument-lib= to allow users to specify
an instrument device library. This is for supporting -finstrument
in device code for debugging/profiling tools.
Differential Revision: https://reviews.llvm.org/D88557
This helper method is useful even outside of Gnu toolchains, so move
it to ToolChain so it can be reused in other toolchains such as Fuchsia.
Differential Revision: https://reviews.llvm.org/D88452
for device simulators
This change separates out the iOS/tvOS/watchOS simulator slices from the "libclang_rt.<os>.a"
fat archive, by moving them out to their own "libclang_rt.<os>sim.a" static archive.
This allows us to build and to link with an arm64 device simulator slice for the simulators running
on Apple Silicons, and to distribute it in one archive alongside the Intel simulator slices.
Differential Revision: https://reviews.llvm.org/D84564
Supersedes D80225. Add --ld-path= to avoid strange target specific
prefixes and make -fuse-ld= focus on its intended job: "linker flavor".
(-f* affects generated code or language features. --ld-path does not
affect codegen, so it is not named -f*)
The way --ld-path= works is similar to "Command Search and Execution" in POSIX.1-2017 2.9.1 Simple Commands.
If --ld-path= specifies
* an absolute path, the value specifies the linker.
* a relative path without a path component separator (/), the value is searched using the -B, COMPILER_PATH, then PATH.
* a relative path with a path component separator, the linker is found relative to the current working directory.
-fuse-ld= and --ld-path= can be composed, e.g. `-fuse-ld=lld --ld-path=/usr/bin/ld.lld`
The driver can base its linker option decision on the flavor -fuse-ld=, but it should not do fragile
flavor checking with --ld-path=.
Reviewed By: whitequark, keith
Differential Revision: https://reviews.llvm.org/D83015
To match GCC (either crossing or not), which doesn't prepend target triple prefixes to `exec_prefixes`.
As an example, powerpc64le-linux-gnu-gcc does not search "powerpc64le-linux-gnu-${name}" in a -B path.
Do not detect device library by default in rocm detector.
Only detect device library in Rocm and HIP toolchain.
Separate detection of HIP runtime and Rocm device library.
Detect rocm path by version file in host toolchains.
Also added detecting rocm version and printing rocm
installation path and version with -v.
Fixed include path and device library detection for
ROCm 3.5.
Added --hip-version option. Renamed --hip-device-lib-path
to --rocm-device-lib-path.
Fixed default value for -fhip-new-launch-api.
Added default -std option for HIP.
Differential Revision: https://reviews.llvm.org/D82930
To support std::complex and some other standard C/C++ functions in HIP device code,
they need to be forced to be __host__ __device__ functions by pragmas. This is done
by some clang standard C++ wrapper headers which are shared between cuda-clang and hip-Clang.
For these standard C++ wapper headers to work properly, specific include path order
has to be enforced:
clang C++ wrapper include path
standard C++ include path
clang include path
Also, these C++ wrapper headers require device version of some standard C/C++ functions
must be declared before including them. This needs to be done by including a default
header which declares or defines these device functions. The default header is always
included before any other headers are included by users.
This patch adds the the default header and include path for HIP.
Differential Revision: https://reviews.llvm.org/D81176
Follow the model used on Linux, where the clang driver passes the
linker a -u switch to force the profile runtime to be linked in,
rather than having every TU emit a dead function with a reference.
Differential Revision: https://reviews.llvm.org/D79835
Add missing files
Summary: The current code for GNU/Linux is actually completely generic, and can be moved to Gnu, so it can benefit GNU/Hurd and GNU/kFreeBSD
Reviewers: kristina, sammccall, lebedev.ri, MaskRay, arsenm, phosek
Reviewed By: MaskRay, phosek
Subscribers: wdng, ormris, emaste, arichardson, krytarowski, cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D73845
Currently the library is separately linked, but this isn't correct to
implement fast math flags correctly. Each module should get the
version of the library appropriate for its combination of fast math
and related flags, with the attributes propagated into its functions
and internalized.
HIP already maintains the list of libraries, but this is not used for
OpenCL. Unfortunately, HIP uses a separate --hip-device-lib argument,
despite both languages using the same bitcode library. Eventually
these two searches need to be merged.
An additional problem is there are 3 different locations the libraries
are installed, depending on which build is used. This also needs to be
consolidated (or at least the search logic needs to deal with this
unnecessary complexity).
Update the sysroot expectation to match other targets and breakout
linux/musl toolchain tests into a new file.
Differential Revision: https://reviews.llvm.org/D77440
Summary: Adds the RedHat Linux triple to the list of 64-bit RISC-V triples.
Without this the gcc libraries wouldn't be found by clang on a redhat/fedora
system, as the search list included `/usr/lib/gcc/riscv64-redhat-linux-gnu`
but the correct path didn't include the `-gnu` suffix.
Reviewers: lenary, asb, dlj
Reviewed By: lenary
Tags: #clang
Differential Revision: https://reviews.llvm.org/D74399
This makes clang somewhat forward-compatible with new CUDA releases
without having to patch it for every minor release without adding
any new function.
If an unknown version is found, clang issues a warning (can be disabled
with -Wno-cuda-unknown-version) and assumes that it has detected
the latest known version. CUDA releases are usually supersets
of older ones feature-wise, so it should be sufficient to keep
released clang versions working with minor CUDA updates without
having to upgrade clang, too.
Differential Revision: https://reviews.llvm.org/D73231
This required some fixes to the generic code for two issues:
1. -fsanitize=safe-stack is default on x86_64-fuchsia and is *not* incompatible with -fsanitize=leak on Fuchisa
2. -fsanitize=leak and other static-only runtimes must not be omitted under -shared-libsan (which is the default on Fuchsia)
Patch By: mcgrathr
Differential Revision: https://reviews.llvm.org/D73397
In Xcode 11, ld added a new flag called -platform_version that can be used instead of the old -<platform>_version_min flags.
The new flag allows Clang to pass the SDK version from the driver to the linker.
This patch adopts the new -platform_version flag in Clang, and starts using it by default,
unless a linker version < 520 is passed to the driver.
Differential Revision: https://reviews.llvm.org/D71579
Summary:
A skeleton of AIX toolchain and system linker support has been introduced in D68340, and this is a follow on patch to it.
This patch adds support to system assembler invocation to the AIX toolchain.
Reviewers: daltenty, hubert.reinterpretcast, jasonliu, Xiangling_L, dlj
Reviewed By: daltenty, hubert.reinterpretcast
Subscribers: wuzish, nemanjai, kbarton, jfb, cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D69620
