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
This patch propagates the -moutline flag when LTO is enabled and avoids
passing it explicitly to the linker plugin.
Differential Revision: https://reviews.llvm.org/D93385
recommit e50465ecef with fix for
regression in lldb tests.
Two issues:
1. the directory part of original .dwo file was dropped
2. if the stem of the .dwo file contains '.', the last dot
and strings after that were removed
This recommit fixes those two issues.
when -gsplit option is used with clang driver, clang driver will create
a filename with .dwo option based on the input file name and pass
it to clang -cc1. This file is used for storing the debug info. Since
HIP generate separate object files for different GPU arch's,
this file should be different for different GPU arch. This patch
adds _ and GPU arch to the stem of the dwo file.
Differential Revision: https://reviews.llvm.org/D87791
gcc translates -gz=zlib to --compress-debug-options=zlib for both assembler and linker
but clang only does this for assembler.
The linker needs --compress-debug-options=zlib option to compress the debug sections
in the generated executable or shared library.
Due to this bug, -gz=zlib has no effect on the generated executable or shared library.
This patch fixes that.
Differential Revision: https://reviews.llvm.org/D87321
This patch is a follow up on https://reviews.llvm.org/D78759.
Extract the HIP Linker script from generic GNU linker,
and move it into HIP ToolChain. Update OffloadActionBuilder
Link actions feature to apply device linking and host linking
actions separately. Using MC Directives, embed the device images
and define symbols.
Reviewers: JonChesterfield, yaxunl
Subscribers: tra, echristo, jdoerfert, msearles, scchan
Differential Revision: https://reviews.llvm.org/D81963
Summary: Before this patch, we use two different ways to pass options to align branch
depending on whether LTO is enabled. For example, `-mbranches-within-32B-boundaries`
w/o LTO and `-Wl,-plugin-opt=-x86-branches-within-32B-boundaries` w/ LTO. It's
inconvenient, so this patch unifies the way: we only need to pass options like
`-mbranches-within-32B-boundaries` to align branches, no matter LTO is enabled or not.
Differential Revision: https://reviews.llvm.org/D80289
Before this patch, it wasn't possible to extend the ThinLTO threads to all SMT/CMT threads in the system. Only one thread per core was allowed, instructed by usage of llvm::heavyweight_hardware_concurrency() in the ThinLTO code. Any number passed to the LLD flag /opt:lldltojobs=..., or any other ThinLTO-specific flag, was previously interpreted in the context of llvm::heavyweight_hardware_concurrency(), which means SMT disabled.
One can now say in LLD:
/opt:lldltojobs=0 -- Use one std::thread / hardware core in the system (no SMT). Default value if flag not specified.
/opt:lldltojobs=N -- Limit usage to N threads, regardless of usage of heavyweight_hardware_concurrency().
/opt:lldltojobs=all -- Use all hardware threads in the system. Equivalent to /opt:lldltojobs=$(nproc) on Linux and /opt:lldltojobs=%NUMBER_OF_PROCESSORS% on Windows. When an affinity mask is set for the process, threads will be created only for the cores selected by the mask.
When N > number-of-hardware-threads-in-the-system, the threads in the thread pool will be dispatched equally on all CPU sockets (tested only on Windows).
When N <= number-of-hardware-threads-on-a-CPU-socket, the threads will remain on the CPU socket where the process started (only on Windows).
Differential Revision: https://reviews.llvm.org/D75153
AddGoldPlugin does more than adding `-plugin path/to/LLVMgold.so`.
It works with lld and GNU ld, and adds other LTO options.
So AddGoldPlugin is no longer a suitable name.
Reviewed By: tejohnson
Differential Revision: https://reviews.llvm.org/D74591
Currently device lib path set by environment variable HIP_DEVICE_LIB_PATH
does not work due to extra "-L" added to each entry.
This patch fixes that by allowing argument name to be empty in addDirectoryList.
Differential Revision: https://reviews.llvm.org/D73299
This started passing target-features on the linker line, not just for RISCV but
for all targets, leading to error messages in Chromium Android build:
'+soft-float-abi' is not a recognized feature for this target (ignoring feature)
'+soft-float-abi' is not a recognized feature for this target (ignoring feature)
See Phabricator review for details.
Reverting until this can be fixed properly.
> Summary:
> 1. enable LTO need to pass target feature and abi to LTO code generation
> RISCV backend need the target feature to decide which extension used in
> code generation.
> 2. move getTargetFeatures to CommonArgs.h and add ForLTOPlugin flag
> 3. add general tools::getTargetABI in CommonArgs.h because different target uses different
> way to get the target ABI.
>
> Patch by Kuan Hsu Chen (khchen)
>
> Reviewers: lenary, lewis-revill, asb, MaskRay
>
> Reviewed By: lenary
>
> Subscribers: hiraditya, dschuff, aheejin, fedor.sergeev, mehdi_amini, inglorion, asb, rbar, johnrusso, simoncook, apazos, sabuasal, niosHD, kito-cheng, shiva0217, jrtc27, MaskRay, zzheng, edward-jones, steven_wu, rogfer01, MartinMosbeck, brucehoult, the_o, dexonsmith, rkruppe, PkmX, jocewei, psnobl, benna, Jim, lenary, s.egerton, pzheng, cfe-commits
>
> Tags: #clang
>
> Differential Revision: https://reviews.llvm.org/D67409
This flag decouples specifying the DWARF version from enabling/disabling
DWARF in general (or the gN level - gmlt/limited/standalone, etc) while
still allowing existing -gdwarf-N flags to override this default.
Patch by Caroline Tice!
Differential Revision: https://reviews.llvm.org/D69822
Summary:
1. enable LTO need to pass target feature and abi to LTO code generation
RISCV backend need the target feature to decide which extension used in
code generation.
2. move getTargetFeatures to CommonArgs.h and add ForLTOPlugin flag
3. add general tools::getTargetABI in CommonArgs.h because different target uses different
way to get the target ABI.
Patch by Kuan Hsu Chen (khchen)
Reviewers: lenary, lewis-revill, asb, MaskRay
Reviewed By: lenary
Subscribers: hiraditya, dschuff, aheejin, fedor.sergeev, mehdi_amini, inglorion, asb, rbar, johnrusso, simoncook, apazos, sabuasal, niosHD, kito-cheng, shiva0217, jrtc27, MaskRay, zzheng, edward-jones, steven_wu, rogfer01, MartinMosbeck, brucehoult, the_o, dexonsmith, rkruppe, PkmX, jocewei, psnobl, benna, Jim, lenary, s.egerton, pzheng, cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D67409
llvm-svn: 374774
This patch removes the remaining part of the OpenMP offload linker scripts which was used for inserting device binaries into the output linked binary. Device binaries are now inserted into the host binary with a help of the wrapper bit-code file which contains device binaries as data. Wrapper bit-code file is dynamically created by the clang driver with a help of new tool clang-offload-wrapper which takes device binaries as input and produces bit-code file with required contents. Wrapper bit-code is then compiled to an object and resulting object is appended to the host linking by the clang driver.
This is the second part of the patch for eliminating OpenMP linker script (please see https://reviews.llvm.org/D64943).
Differential Revision: https://reviews.llvm.org/D68166
llvm-svn: 374219
Summary:
For Gnu, FreeBSD and NetBSD, this option forces linking with the static
OpenMP host runtime (similar to -static-libgcc and -static-libstdcxx).
Android's NDK will start the shared OpenMP runtime in addition to the static
libomp. In this scenario, the linker will prefer to use the shared library by
default. Add this option to enable linking with the static libomp.
Reviewers: Hahnfeld, danalbert, srhines, joerg, jdoerfert
Subscribers: guansong, cfe-commits
Tags: #clang
Fixes https://github.com/android-ndk/ndk/issues/1028
Differential Revision: https://reviews.llvm.org/D67200
llvm-svn: 371437
This introduces a support for multilibs to Fuchsia driver. Unlike the
existing multilibs that are used primarily for handling different
architecture variants, we use multilibs to handle different variants
of Clang runtime libraries: -fsanitize=address and -fno-exceptions
are the two we support initially. This replaces the existing support
for sanitized runtimes libraries that was only used by Fuchsia driver
and it also refactors some of the logic to allow sharing between GNU
and Fuchsia drivers.
Differential Revision: https://reviews.llvm.org/D61040
llvm-svn: 359360
to reflect the new license.
We understand that people may be surprised that we're moving the header
entirely to discuss the new license. We checked this carefully with the
Foundation's lawyer and we believe this is the correct approach.
Essentially, all code in the project is now made available by the LLVM
project under our new license, so you will see that the license headers
include that license only. Some of our contributors have contributed
code under our old license, and accordingly, we have retained a copy of
our old license notice in the top-level files in each project and
repository.
llvm-svn: 351636
This is an updated version of the D54576, which was reverted.
Problem was that SplitDebugName calls the InputInfo::getFilename
which asserts if InputInfo given is not of type Filename:
const char *getFilename() const {
assert(isFilename() && "Invalid accessor.");
return Data.Filename;
}
At the same time at that point, it can be of type Nothing and
we need to use getBaseInput(), like original code did.
Differential revision: https://reviews.llvm.org/D55006
llvm-svn: 348352
This reverts commit r347035 as it introduced assertion failures under
certain conditions. More information can be found here:
https://reviews.llvm.org/rL347035
llvm-svn: 347676
This should be NFC change.
SplitDebugName recently started to accept the `Output` that
can be used to simplify the logic a bit, also it
seems that code in SplitDebugName that uses
OPT_fdebug_compilation_dir is simply dead.
Differential revision: https://reviews.llvm.org/D54576
llvm-svn: 347035
The DWARF5 specification says(Appendix F.1):
"The sections that do not require relocation, however, can be
written to the relocatable object (.o) file but ignored by the
linker or they can be written to a separate DWARF object (.dwo)
file that need not be accessed by the linker."
The first part describes a single file split DWARF feature and there
is no way to trigger this behavior atm.
Fortunately, no many changes are required to keep *.dwo sections
in a .o, the patch does that.
Differential revision: https://reviews.llvm.org/D52296
llvm-svn: 346837
When using sanitizers, add <resource_dir>/<target>/lib/<sanitizer>
to the list of library paths to support using sanitized version of
runtime libraries if available.
Differential Revision: https://reviews.llvm.org/D53487
llvm-svn: 345537
To support linking device code in different source files, it is necessary to
embed fat binary at host linking stage.
This patch emits an external symbol for fat binary in host codegen, then
embed the fat binary by lld through a linker script.
Differential Revision: https://reviews.llvm.org/D46472
llvm-svn: 332724
This patch updates AddGoldPlugin to pass stats-file to the Gold plugin,
if -save-stats is passed. It also moves the save-stats option handling
to a helper function tools::getStatsFileName.
Reviewers: tejohnson, mehdi_amini, compnerd
Reviewed By: tejohnson, compnerd
Differential Revision: https://reviews.llvm.org/D45771
llvm-svn: 330422
This implements support for the previously ignored flag
`-falign-functions`. This allows the frontend to request alignment on
function definitions in the translation unit where they are not
explicitly requested in code. This is compatible with the GCC behaviour
and the ICC behaviour.
The scalar value passed to `-falign-functions` aligns functions to a
power-of-two boundary. If flag is used, the functions are aligned to
16-byte boundaries. If the scalar is specified, it must be an integer
less than or equal to 4096. If the value is not a power-of-two, the
driver will round it up to the nearest power of two.
llvm-svn: 330378
Summary:
This change fixes http://llvm.org/PR36985 to define a single place in
CommonArgs.{h,cpp} where XRay runtime flags and link-time dependencies
are processed for all toolchains that support XRay instrumentation. This
is a refactoring of the same functionality spread across multiple
toolchain definitions.
Reviewers: echristo, devnexen, eizan
Reviewed By: eizan
Subscribers: emaste, cfe-commits
Differential Revision: https://reviews.llvm.org/D45243
llvm-svn: 329372
The commit r310291 introduced the failure. r310332 was a test fix commit and
r310300 was a followup commit. I reverted these two to avoid merge conflicts
when reverting.
The 'openmp-offload.c' test is failing on Darwin because the following
run lines:
// RUN: touch %t1.o
// RUN: touch %t2.o
// RUN: %clang -### -no-canonical-prefixes -fopenmp=libomp -fopenmp-targets=nvptx64-nvidia-cuda -save-temps -no-canonical-prefixes %t1.o %t2.o 2>&1 \
// RUN: | FileCheck -check-prefix=CHK-TWOCUBIN %s
trigger the following assertion:
Driver.cpp:3418:
assert(CachedResults.find(ActionTC) != CachedResults.end() &&
"Result does not exist??");
llvm-svn: 310345
Summary: We need to be able to disable samplepgo for specific files by supporting -fno-auto-profile and -fno-profile-sample-use
Reviewers: davidxl, dnovillo, echristo
Reviewed By: echristo
Subscribers: echristo, cfe-commits
Differential Revision: https://reviews.llvm.org/D31213
llvm-svn: 298446
Summary:
(This is a move-only refactoring patch. There are no functionality changes.)
This patch splits apart the Clang driver's tool and toolchain implementation
files. Each target platform toolchain is moved to its own file, along with the
closest-related tools. Each target platform toolchain has separate headers and
implementation files, so the hierarchy of classes is unchanged.
There are some remaining shared free functions, mostly from Tools.cpp. Several
of these move to their own architecture-specific files, similar to r296056. Some
of them are only used by a single target platform; since the tools and
toolchains are now together, some helpers now live in a platform-specific file.
The balance are helpers related to manipulating argument lists, so they are now
in a new file pair, CommonArgs.h and .cpp.
I've tried to cluster the code logically, which is fairly straightforward for
most of the target platforms and shared architectures. I think I've made
reasonable choices for these, as well as the various shared helpers; but of
course, I'm happy to hear feedback in the review.
There are some particular things I don't like about this patch, but haven't been
able to find a better overall solution. The first is the proliferation of files:
there are several files that are tiny because the toolchain is not very
different from its base (usually the Gnu tools/toolchain). I think this is
mostly a reflection of the true complexity, though, so it may not be "fixable"
in any reasonable sense. The second thing I don't like are the includes like
"../Something.h". I've avoided this largely by clustering into the current file
structure. However, a few of these includes remain, and in those cases it
doesn't make sense to me to sink an existing file any deeper.
Reviewers: rsmith, mehdi_amini, compnerd, rnk, javed.absar
Subscribers: emaste, jfb, danalbert, srhines, dschuff, jyknight, nemanjai, nhaehnle, mgorny, cfe-commits
Differential Revision: https://reviews.llvm.org/D30372
llvm-svn: 297250
Pushpinder Singh