-shared-libasan is likely to be used as a link flag if the user is using
the GCC-style clang driver.
This logic is already tested in clang-cl tests, and the new flag to
exercise it will be covered by asan tests.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@285820 91177308-0d34-0410-b5e6-96231b3b80d8
This code path is used when generating the path to libLTO.dylib, which
is passed to the linker as `-lto_library'.
Without this, if clang is invoked through a symlink, libLTO is
searched in a path relative to where the symlink is instead of
where clang is actually installed.
Fix PR30811.
Patch by: Jack Howarth
Differential Revision: https://reviews.llvm.org/D26116
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@285525 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
This patch adds the support to create jobs for the `OffloadBundlingAction` which will invoke the `clang-offload-bundler` tool to unbundle input files.
Unlike other actions, unbundling actions have multiple outputs. Therefore, this patch adds the required changes to have a variant of `Tool::ConstructJob` with multiple outputs.
The way the naming of the results is implemented is also slightly modified so that the same action can use a different offloading prefix for each use by the different offloading actions.
With this patch, it is possible to compile a functional OpenMP binary with offloading support, even with separate compilation.
Reviewers: echristo, tra, jlebar, ABataev, hfinkel
Subscribers: mkuron, whchung, mehdi_amini, cfe-commits, Hahnfeld, andreybokhanko, arpith-jacob, carlo.bertolli, caomhin
Differential Revision: https://reviews.llvm.org/D21857
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@285326 91177308-0d34-0410-b5e6-96231b3b80d8
Summary: This patch adds the support to create a job for the `OffloadBundlingAction` which will invoke the `clang-offload-bundler` tool.
Reviewers: echristo, tra, jlebar, ABataev, hfinkel
Subscribers: whchung, mehdi_amini, cfe-commits, Hahnfeld, andreybokhanko, arpith-jacob, carlo.bertolli, caomhin
Differential Revision: https://reviews.llvm.org/D21856
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@285325 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
This patch adds logic to create jobs for OpenMP offloading actions by:
- tuning the jobs result information to use the offloading prefix even for (device) linking actions.
- replacing the device inputs of the host linking jobs by a linker script that embed them in the right sections.
Reviewers: echristo, tra, jlebar, rsmith, ABataev, hfinkel
Subscribers: mkuron, whchung, mehdi_amini, cfe-commits, Hahnfeld, andreybokhanko, arpith-jacob, carlo.bertolli, caomhin
Differential Revision: https://reviews.llvm.org/D21847
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@285319 91177308-0d34-0410-b5e6-96231b3b80d8
Summary: This patch adds new logic to create the necessary tool chains to support offloading for OpenMP. The OpenMP related options are checked and the tool chains created accordingly. Diagnostics are emitted in case the options are illegal or express unknown targets.
Reviewers: echristo, tra, jlebar, rsmith, ABataev, hfinkel
Subscribers: whchung, mkuron, mehdi_amini, cfe-commits, Hahnfeld, arpith-jacob, carlo.bertolli, caomhin
Differential Revision: https://reviews.llvm.org/D21843
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@285311 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
Added the code which explicitly emits an error in Clang in case
`-fxray-instrument` is passed, but XRay is not supported for the
selected target.
Reviewers: rsmith, aaron.ballman, rnk, dberris
Differential Revision: https://reviews.llvm.org/D24799
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@285266 91177308-0d34-0410-b5e6-96231b3b80d8
We're only doing it with -flto currently, however it never "hurt"
to pass it, and users that are linking without -flto can get in
trouble if one of the dependency (a static library for instance)
contains bitcode.
Differential Revision: https://reviews.llvm.org/D25932
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@285254 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
This is only forced on if there is no non-Cortex-A53 CPU specified as
well. Android's platform and NDK builds need to assume that the code can
be run on Cortex-A53 devices, so we always enable the fix unless we know
specifically that the code is only running on a different kind of CPU.
Reviewers: cfe-commits
Subscribers: aemerson, rengolin, tberghammer, pirama, danalbert
Differential Revision: https://reviews.llvm.org/D25761
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@285127 91177308-0d34-0410-b5e6-96231b3b80d8
Recent versions of ld64 run a deduplicate pass, which is on by default.
Disable the pass by using -no_deduplicate in certain condition and
enhance total compile time.
rdar://problem/25455336
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@284798 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
These options need to be passed to the plugin in order to have
an effect on LTO/ThinLTO compiles.
Reviewers: mehdi_amini, pcc
Subscribers: jfb, dschuff, mehdi_amini, cfe-commits
Differential Revision: https://reviews.llvm.org/D24644
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@284140 91177308-0d34-0410-b5e6-96231b3b80d8
The backend now has the capability to save information from optimizations, the
same information that can be used to generate optimization diagnostics but in
machine-consumable form, into an output file. This can be enabled when using
opt (see r282539), and this change enables it when using clang. The idea is
that other tools will be able to consume these files, and perhaps in
combination with the original source code, produce various kinds of
optimization reports for users (and for compiler developers).
We now have at-least two tools that can consume these files:
* tools/llvm-opt-report
* utils/opt-viewer
Using the flag -fsave-optimization-record will cause the YAML file to be
generated; the file name will be based on the output file name (if we're using
-c or -S and have an output name), or the input file name. When we're using
CUDA, or some other offloading mechanism, separate files are generated for each
backend target. The output file name can be specified by the user using
-foptimization-record-file=filename.
Differential Revision: https://reviews.llvm.org/D25225
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@283834 91177308-0d34-0410-b5e6-96231b3b80d8
The -gmodules option is all about putting debug type info into clang
modules and for line tables the type information is irrelevant, so
combining these two options makes no sense.
This commmit fixes the behavior to match the one documented on the
clang man page: the last -g... option wins.
<rdar://problem/27059770>
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@283810 91177308-0d34-0410-b5e6-96231b3b80d8
We have a loop-rerolling optimization which can be enabled by using
-freroll-loops. While sometimes loops are hand-unrolled for performance
reasons, when optimizing for size, we should always undo this manual
optimization to produce smaller code (our optimizer's unroller will still
unroll the rerolled loops if it thinks that is a good idea).
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@283685 91177308-0d34-0410-b5e6-96231b3b80d8
Provide toolchain and tool support for Fuchsia operating system.
Fuchsia uses compiler-rt as the runtime library and libc++, libc++abi
and libunwind as the C++ standard library. lld is used as a default
linker.
Differential Revision: https://reviews.llvm.org/D25117
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@283420 91177308-0d34-0410-b5e6-96231b3b80d8
Added the code which explicitly emits an error in Clang in case
`-fxray-instrument` is passed, but XRay is not supported for the
selected target.
Author: rSerge
Reviewers: dberris, rsmith, aaron.ballman, rnk
Subscribers: cfe-commits, iid_iunknown
Differential Revision: https://reviews.llvm.org/D24799
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@283193 91177308-0d34-0410-b5e6-96231b3b80d8
Enable soft-float support on PPC64, as the backend now supports it. Also, the
backend now uses -hard-float instead of +soft-float, so set the target features
accordingly.
Fixes PR26970.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@283061 91177308-0d34-0410-b5e6-96231b3b80d8
assume that ::operator new provides no more alignment than is necessary for any
primitive type, except when we're on a GNU OS, where glibc's malloc guarantees
to provide 64-bit alignment on 32-bit systems and 128-bit alignment on 64-bit
systems. This can be controlled by the command-line -fnew-alignment flag.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@282974 91177308-0d34-0410-b5e6-96231b3b80d8
Avoid failing in the backend when the rewrite map does not exist. Rather check
that the map exists in the frontend before handing it off to the backend. Add
the missing rewrite maps that the tests were referencing.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@282379 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
Currently, a linker option must be used to control the backend
parallelism of ThinLTO. The linker option varies depending on the
linker (e.g. gold vs ld64). Add a new clang option -flto-jobs=N
to control this.
I've added in the wiring to pass this to the gold plugin. I also
added in the logic to pass this down in the form I understand that
ld64 uses on MacOS, for the darwin target.
Reviewers: mehdi_amini, dexonsmith
Subscribers: mehdi_amini, cfe-commits
Differential Revision: https://reviews.llvm.org/D24826
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@282291 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
The ASAN unittests are failing (check-asan-dynamic) due to an incorrect symbol name:
```
LINK : error LNK2001: unresolved external symbol ___asan_seh_interceptor
```
On win64, the linker is not adding an extra underscore. This was correctly fixed in the same file for other uses.
After that patch, most of the unittests are passing, but some related to SEH needs to be fixed.
```
Failing Tests (4):
AddressSanitizer-x86_64-windows-dynamic :: TestCases/Windows/dll_intercept_memchr.cc
AddressSanitizer-x86_64-windows-dynamic :: TestCases/Windows/dll_intercept_memcpy_indirect.cc
AddressSanitizer-x86_64-windows-dynamic :: TestCases/Windows/dll_seh.cc
AddressSanitizer-x86_64-windows-dynamic :: TestCases/Windows/seh.cc
Expected Passes : 339
Passes With Retry : 3
Expected Failures : 16
Unsupported Tests : 152
Unexpected Failures: 4
```
Reviewers: rnk, kcc, majnemer
Subscribers: majnemer, chrisha, cfe-commits
Differential Revision: https://reviews.llvm.org/D24841
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@282251 91177308-0d34-0410-b5e6-96231b3b80d8
Original commit message:
Add -fdiagnostics-show-hotness
Summary:
I've recently added the ability for optimization remarks to include the
hotness of the corresponding code region. This uses PGO and allows
filtering of the optimization remarks by relevance. The idea was first
discussed here:
http://thread.gmane.org/gmane.comp.compilers.llvm.devel/98334
The general goal is to produce a YAML file with the remarks. Then, an
external tool could dynamically filter these by hotness and perhaps by
other things.
That said it makes sense to also expose this at the more basic level
where we just include the hotness info with each optimization remark.
For example, in D22694, the clang flag was pretty useful to measure the
overhead of the additional analyses required to include hotness.
(Without the flag we don't even run the analyses.)
For the record, Hal has already expressed support for the idea of this
patch on IRC.
Differential Revision: https://reviews.llvm.org/D23284
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@281293 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
I've recently added the ability for optimization remarks to include the
hotness of the corresponding code region. This uses PGO and allows
filtering of the optimization remarks by relevance. The idea was first
discussed here:
http://thread.gmane.org/gmane.comp.compilers.llvm.devel/98334
The general goal is to produce a YAML file with the remarks. Then, an
external tool could dynamically filter these by hotness and perhaps by
other things.
That said it makes sense to also expose this at the more basic level
where we just include the hotness info with each optimization remark.
For example, in D22694, the clang flag was pretty useful to measure the
overhead of the additional analyses required to include hotness.
(Without the flag we don't even run the analyses.)
For the record, Hal has already expressed support for the idea of this
patch on IRC.
Differential Revision: https://reviews.llvm.org/D23284
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@281276 91177308-0d34-0410-b5e6-96231b3b80d8
-fprofile-dir=path allows the user to specify where .gcda files should be
emitted when the program is run. In particular, this is the first flag that
causes the .gcno and .o files to have different paths, LLVM is extended to
support this. -fprofile-dir= does not change the file name in the .gcno (and
thus where lcov looks for the source) but it does change the name in the .gcda
(and thus where the runtime library writes the .gcda file). It's different from
a GCOV_PREFIX because a user can observe that the GCOV_PREFIX_STRIP will strip
paths off of -fprofile-dir= but not off of a supplied GCOV_PREFIX.
To implement this we split -coverage-file into -coverage-data-file and
-coverage-notes-file to specify the two different names. The !llvm.gcov
metadata node grows from a 2-element form {string coverage-file, node dbg.cu}
to 3-elements, {string coverage-notes-file, string coverage-data-file, node
dbg.cu}. In the 3-element form, the file name is already "mangled" with
.gcno/.gcda suffixes, while the 2-element form left that to the middle end
pass.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@280306 91177308-0d34-0410-b5e6-96231b3b80d8
I tested the cases involving split-dwarf + gmlt +
no-split-dwarf-inlining, but didn't verify the simpler case without
gmlt.
The logic is, admittedly, a little hairy, but seems about as simple as I
could wrangle it.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@280290 91177308-0d34-0410-b5e6-96231b3b80d8
r280133. Original commit message:
C++ Modules TS: driver support for building modules.
This works as follows: we add --precompile to the existing gamut of options for
specifying how far to go when compiling an input (-E, -c, -S, etc.). This flag
specifies that an input is taken to the precompilation step and no further, and
this can be specified when building a .pcm from a module interface or when
building a .pch from a header file.
The .cppm extension (and some related extensions) are implicitly recognized as
C++ module interface files. If --precompile is /not/ specified, the file is
compiled (via a .pcm) to a .o file containing the code for the module (and then
potentially also assembled and linked, if -S, -c, etc. are not specified). We
do not yet suppress the emission of object code for other users of the module
interface, so for now this will only work if everything in the .cppm file has
vague linkage.
As with the existing support for module-map modules, prebuilt modules can be
provided as compiler inputs either via the -fmodule-file= command-line argument
or via files named ModuleName.pcm in one of the directories specified via
-fprebuilt-module-path=.
This also exposes the -fmodules-ts cc1 flag in the driver. This is still
experimental, and in particular, the concrete syntax is subject to change as
the Modules TS evolves in the C++ committee. Unlike -fmodules, this flag does
not enable support for implicitly loading module maps nor building modules via
the module cache, but those features can be turned on separately and used in
conjunction with the Modules TS support.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@280134 91177308-0d34-0410-b5e6-96231b3b80d8
Hans Wennborg