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
to CC1, which are translated to function attributes and can e.g. be mapped on
build attributes FP_exceptions and FP_denormal. Setting these build attributes
allows better selection of floating point libraries.
Differential Revision: https://reviews.llvm.org/D23840
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@280064 91177308-0d34-0410-b5e6-96231b3b80d8
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@280035 91177308-0d34-0410-b5e6-96231b3b80d8
Clang tracks only start columns, not start-end ranges. CodeView allows for that, but the VS debugger doesn't handle anything less than a complete range well--it either highlights the wrong part of a statement or truncates source lines in the assembly view. It's better to have no column information at all.
So by default, we'll omit the column information for CodeView targeting Windows.
Since the column info is still useful for sanitizers, I've promoted -gcolumn-info (and -gno-column-info) to a CoreOption and added a couple tests to make sure that works for clang-cl.
Differential Revision: https://reviews.llvm.org/D23720
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@279765 91177308-0d34-0410-b5e6-96231b3b80d8
If the inline info is not duplicated into the skeleton CU, then there's
value in using -gsplit-dwarf and -gmlt together (to keep all those extra
subprograms out of the skeleton CU, while also producing smaller .dwo
files)
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@279687 91177308-0d34-0410-b5e6-96231b3b80d8
In cases where .dwo/.dwp files are guaranteed to be available, skipping
the extra online (in the .o file) inline info can save a substantial
amount of space - see the original r221306 for more details there.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@279651 91177308-0d34-0410-b5e6-96231b3b80d8
iOS (and other 32-bit ARM variants) always require a valid frame pointer to
improve backtraces. Previously the -fomit-frame-pointer and
-momit-leaf-frame-pointer options were being silently discarded via hacks in
the backend. It's better if Clang configures itself to emit the correct IR and
warns about (ignored) attempts to override this.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@279546 91177308-0d34-0410-b5e6-96231b3b80d8
clang already treats all inputs as utf-8. Warn if anything but utf-8 is passed.
Do this by mapping source-charset to finput-charset, which already behaves like
this. Slightly tweak finput-charset to accept "utf-8" case-insensitively. This
matches gcc's and cl.exe's behavior, and IANA says that character set names are
case-insensitive.
https://reviews.llvm.org/D23807
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@279531 91177308-0d34-0410-b5e6-96231b3b80d8
In this mode, there is no need to load any module map and the programmer can
simply use "@import" syntax to load the module directly from a prebuilt
module path. When loading from prebuilt module path, we don't support
rebuilding of the module files and we ignore compatible configuration
mismatches.
rdar://27290316
Differential Revision: http://reviews.llvm.org/D23125
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@279096 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
There's no point to --cuda-path if we then go and include /usr/include
first. And if you install the right packages, Ubuntu will install (very
old) CUDA headers there.
Reviewers: tra
Subscribers: cfe-commits, Prazek
Differential Revision: https://reviews.llvm.org/D23341
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@278734 91177308-0d34-0410-b5e6-96231b3b80d8
Bruno Cardoso Lopes