It doesn't make any sense to enable -gmlt with -gsplit-dwarf, since
-gmlt is designed for on-line symbolication (and -gsplit-dwarf normally
emits all the -gmlt data into the .o anyway - so there's nothing to
split out except redundant/duplicate info).
With this change they override each other, -gmlt -gsplit-dwarf is the
same as -gsplit-dwarf and -gsplit-dwarf -gmlt is the same as -gmlt.
llvm-svn: 243694
Copying the already existing code for x86 to ARM to set the correct CPU
features when using -mcpu=native. We can already detect the CPU name
but we were not setting the correct feature bits.
Moving fpu/hwdiv down to make sure they override whatever we set the
default to be.
No tests because this is native detection, and not all ARM-enabled builds
will hapen at a specific CPU, or even ARM. I have tested locally and it
works as expected.
Fixes PR12794.
llvm-svn: 243656
The z13 vector facility has an associated language extension,
closely modeled on AltiVec/VSX. The main differences are:
- vector long, vector float and vector pixel are not supported
- vector long long and vector double are supported (like VSX)
- comparison operators return a vector rather than a scalar integer
- shift operators behave like the OpenCL shift operators
- vector bool is only supported as argument to certain operators;
some operators allow mixing a bool with a non-bool vector
This patch adds clang support for the extension. It is closely modelled
on the AltiVec support. Similarly to the -faltivec option, there's a
new -fzvector option to enable the extensions (as well as an -mzvector
alias for compatibility with GCC). There's also a separate LangOpt.
The extension as implemented here is intended to be compatible with
the -mzvector extension recently implemented by GCC.
Based on a patch by Richard Sandiford.
Differential Revision: http://reviews.llvm.org/D11001
llvm-svn: 243642
This commit changes the driver to save subtarget feature "+strict-align"
to the IR instead of using backend option "aarch64-strict-align". This is
needed for LTO.
rdar://problem/21529937
llvm-svn: 243518
This commit changes the driver to save subtarget feature "+strict-align" to the
IR instead of using backend option "arm-strict-align". This is needed for LTO.
Also, move the logic in ARM backend that was deciding whether strict alignment
should be forced to the front-end.
rdar://problem/21529937
http://reviews.llvm.org/D11472
llvm-svn: 243489
This will be used for old targets like Android that do not
support ELF TLS models.
Differential Revision: http://reviews.llvm.org/D10524
llvm-svn: 243441
This patch allows Clang to pass on -Wa,-mfpu, -Wa,-mhwdiv and
-Wa,-mcpu to the integrated assembler (via target-features), but
-march is still not being passed, but validated.
In case the command line has both -mxxx and -Wa,-mxxx, we warn
that the naked one will not be used in assembler mode.
llvm-svn: 243353
To be able to handle -Wa, options in the assembler (ClangAs), we need to
make the handling of options based on the value of the options, not direct
Arguments from the list, since the list is immutable.
No functional change in this patch, but this allows validating of -Wa,-mfpu
and friends in the same way we validate -mfpu and friends, *just* for the
assembler.
llvm-svn: 243352
Also rename XCore (the toolchain) to XCoreToolChain since XCore is
also a namespace for its tools.
Differential Revision: http://reviews.llvm.org/D10609
llvm-svn: 243279
Currently trigger to select hard-float linker is only based of -gnueabihf
appearing in target triplet, but we should also select it when hardfloat
is requested via cmdline.
Patch by Khem Raj.
llvm-svn: 243262
We had multiple bugs here:
- We didn't support multiple optimization options in one argument.
e.g. -O2y-
- We didn't correctly expand -O[12dx] to their respective options.
- We treated -O1 as clang -O1 instead of clang -Os.
- We treated -Ox as clang -O3 instead of clang -O2. In fact, cl's -Ox
option is *less* powerful than cl's -O2 option despite -Ox described
as "Full Optimization".
This fixes PR24003.
llvm-svn: 243261
option "-aarch64-reserve-x18".
This change is needed since backend options do not make it to the backend
when doing LTO and are not capable of changing the behavior of code-gen
passes on a per-function basis.
rdar://problem/21529937
Differential Revision: http://reviews.llvm.org/D11462
llvm-svn: 243185
The flag allows users to specify that they do not want the object file
to have any implicit /defaultlib directives.
This fixes PR24236.
llvm-svn: 243097
Currently, for --rtlib=compiler-rt on GNU systems, we're assuming
that one has libgcc_s and libgcc_eh as low-level libraries, which
when used in conjunction with -lunwind or -lc++abi, breaks that
assumption.
My original fix was wrong, and this patch reverts it to prepare for
a new flag to choose the unwinder/C++ libraries. For the time being,
people can use "-lgcc_s -lgcc_eh" or "-lunwind -lc++abi" or any
combination they need explicitly.
llvm-svn: 243025
Now clang should be able to use compiler-rt and libc++ on mingw.
Based on a patch by Martell Malone.
Differential Revision: http://reviews.llvm.org/D11237
llvm-svn: 242905
option "-arm-reserve-r9".
This recommits r242736, which had to be reverted because the llvm-side
change that was committed in r242737 caused the number of subtarget
features to go over the limit of 64.
This change is needed since backend options do not make it to the backend
when doing LTO and are not capable of changing the behavior of code-gen
passes on a per-function basis.
rdar://problem/21529937
Differential Revision: http://reviews.llvm.org/D11319
llvm-svn: 242755
r242737 caused builds to fail with the following error message, so I'm
reverting the clang side change too:
error:Too many subtarget features! Bump MAX_SUBTARGET_FEATURES.
llvm-svn: 242741
option "-arm-reserve-r9".
This change is needed since backend options do not make it to the backend
when doing LTO and are not capable of changing the behavior of code-gen
passes on a per-function basis.
rdar://problem/21529937
Differential Revision: http://reviews.llvm.org/D11319
llvm-svn: 242736
GCC allows case-insensitive values for -mcpu, -march and -mtune options.
This patch implements the same behaviour for the -mtune option for the AArch64 target.
Differential Revision: http://reviews.llvm.org/D10563
llvm-svn: 242663
Summary:
This is a minimal toolchain, which sets the integrated assembler as default,
and uses lld for linking.
Reviewers: arsenm, mcrosier
Subscribers: cfe-commits
Differential Revision: http://reviews.llvm.org/D10700
llvm-svn: 242601
Currently, -save-temp will cause ObjCARC optimization to be dropped,
sanitizer pass to run early in the pipeline, and profiling
instrumentation to run twice.
Fix the issue by properly disable all passes in the optimization
pipeline when generating bitcode output and parse some of the Language
Options even when the input is bitcode so the passes can be setup
correctly.
llvm-svn: 242565
Guessing which file name to replace based on the -main-file-name
argument to -cc1 is flawed. Instead, keep track of which arguments are
inputs to each command.
llvm-svn: 242504
"-arm-use-movt=0".
This change is needed since backend options do not make it to the backend
when doing LTO and are not capable of changing the behavior of code-gen
passes on a per-function basis.
rdar://problem/21529937
Differential Revision: http://reviews.llvm.org/D11025
llvm-svn: 242368
Rather than making -fexceptions a core option that enables C++ EH in
clang-cl, users can use the '-Xclang -fexceptions -Xclang
-fcxx-exceptions' flag set. We weren't going to expose -fexceptions in
clang-cl in the long run, so this way we don't add and then remove a
flag.
llvm-svn: 242176
We will still default to ld until such a time lld become a
stable release. lld supports arm NT under the machine name "thumb2pe".
http://reviews.llvm.org/D11088
Patch by Martell Malone
Reviewed by Reid Kleckner
llvm-svn: 242121
NOTE: reverts r242077 to reinstate r242058, r242065, 242067
and includes fix for OS X test failures.
- Changed driver pipeline to compile host and device side of CUDA
files and incorporate results of device-side compilation into host
object file.
- Added a test for cuda pipeline creation in clang driver.
New clang options:
--cuda-host-only - Do host-side compilation only.
--cuda-device-only - Do device-side compilation only.
--cuda-gpu-arch=<ARCH> - specify GPU architecture for device-side
compilation. E.g. sm_35, sm_30. Default is sm_20. May be used more
than once in which case one device-compilation will be done per
unique specified GPU architecture.
Differential Revision: http://reviews.llvm.org/D9509
llvm-svn: 242085
The tests were failing on OS X.
Revert "[cuda] Driver changes to compile and stitch together host and device-side CUDA code."
Revert "Fixed regex to properly match '64' in the test case."
Revert "clang/test/Driver/cuda-options.cu REQUIRES clang-driver, at least."
llvm-svn: 242077
- Changed driver pipeline to compile host and device side of CUDA
files and incorporate results of device-side compilation into host
object file.
- Added a test for cuda pipeline creation in clang driver.
New clang options:
--cuda-host-only - Do host-side compilation only.
--cuda-device-only - Do device-side compilation only.
--cuda-gpu-arch=<ARCH> - specify GPU architecture for device-side
compilation. E.g. sm_35, sm_30. Default is sm_20. May be used more
than once in which case one device-compilation will be done per
unique specified GPU architecture.
Differential Revision: http://reviews.llvm.org/D9509
llvm-svn: 242058
We don't need any more bug reports from users telling us that MSVC-style
C++ exceptions are broken. Developers and adventurous users can still
test the existing functionality by passing along -fexceptions to either
clang or clang-cl.
llvm-svn: 241952
All of the ABIs we support are altivec style anyhow and so the option
doesn't make much sense with the modern ABIs. We could make this a more
noisy ignore, but it would break builds for projects that just pass
it along by default because of historical reasons.
llvm-svn: 241925
The function is massively large and GCC is emitting stack overflow
errors when building it (stack, as counted by the compiler, grows to
more than 16Kb).
The new flag processing logic added in r241825 took it over the limit.
llvm-svn: 241918
This patch adds support for specifying where the profile is emitted in a
way similar to GCC. These flags are used to specify directories instead
of filenames. When -fprofile-generate=DIR is used, the compiler will
generate code to write to <DIR>/default.profraw.
The patch also adds a couple of extensions: LLVM_PROFILE_FILE can still be
used to override the directory and file name to use and -fprofile-use
accepts both directories and filenames.
To simplify the set of flags used in the backend, all the flags get
canonicalized to -fprofile-instr-{generate,use} when passed to the
backend. The decision to use a default name for the profile is done
in the driver.
llvm-svn: 241825
For Mips direct-to-nacl, the goal is to be close to le32 front-end and
use Mips32EL backend. This patch defines new NaClMips32ELTargetInfo and
modifies it slightly to be close to le32. It also adds necessary parts,
inline with ARM and X86.
Differential Revision: http://reviews.llvm.org/D10739
llvm-svn: 241678
"-arm-long-calls".
This change allows using -mlong-calls/-mno-long-calls for LTO and enabling or
disabling long call on a per-function basis.
rdar://problem/21529937
Differential Revision: http://reviews.llvm.org/D9414
llvm-svn: 241565
The patch is the same except for the addition of a new test for the
issue that required reverting the dependent llvm commit.
--Original Commit Message--
Pass down the -flto option to the -cc1 job, and from there into the
CodeGenOptions and onto the PassManagerBuilder. This enables gating
the new EliminateAvailableExternally module pass on whether we are
preparing for LTO.
If we are preparing for LTO (e.g. a -flto -c compile), the new pass is not
included as we want to preserve available externally functions for possible
link time inlining.
llvm-svn: 241467
No more hardcoded paths: clang will use -sysroot as gcc root location if
provided. Otherwise, it will search for gcc on the path. If not found it
will use the driver installed location.
http://reviews.llvm.org/D5268
Patch by Ruben Van Boxem, Martell Malone, Yaron Keren.
Reviewed by Reid Kleckner.
llvm-svn: 241241
On Windows the user may invoke the linker directly, so we might not have an
opportunity to add runtime library flags to the linker command line. Instead,
instruct the code generator to embed linker directive in the object file
that cause the required runtime libraries to be linked.
We might also want to do something similar for ASan, but it seems to have
its own special complexities which may make this infeasible.
Differential Revision: http://reviews.llvm.org/D10862
llvm-svn: 241225
