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
llvm-svn: 278734
We're only going to provide support for using PIE on architectures that
provide PC-relative addressing. i686 is not one of those, so add the
necessary bits for only passing in -pie -zrelro conditionally.
llvm-svn: 278395
On Linux we pass in -fomit-frame-pointer flags (and similar)
automatically if optimization is enabled. Let's do the same thing on
CloudABI. Without this, Clang seems to run out of registers quite
quickly while trying to build code with inline assembly.
llvm-svn: 278393
Let the driver pass the option to frontend. Do not set precision metadata for division instructions when this option is set. Set function attribute "correctly-rounded-divide-sqrt-fp-math" based on this option.
Differential Revision: https://reviews.llvm.org/D22940
llvm-svn: 278155
It's surprising that you have to pass /Z7 in addition to -gcodeview to
get debug info. The sanitizer runtime, for example, expects that if the
compiler supports the -gline-tables-only flag, then it will emit debug
info.
llvm-svn: 278139
This patch (with the corresponding ARM backend patch) adds support for
some new relocation models:
* Read-only position independence (ROPI): Code and read-only data is accessed
PC-relative. The offsets between all code and RO data sections are known at
static link time.
* Read-write position independence (RWPI): Read-write data is accessed relative
to a static base register. The offsets between all writeable data sections
are known at static link time.
These two modes are independent (they specify how different objects
should be addressed), so they can be used individually or together.
These modes are intended for bare-metal systems or systems with small
real-time operating systems. They are designed to avoid the need for a
dynamic linker, the only initialisation required is setting the static
base register to an appropriate value for RWPI code.
There is one C construct not currently supported by these modes: global
variables initialised to the address of another global variable or
function, where that address is not known at static-link time. There are
a few possible ways to solve this:
* Disallow this, and require the user to write their own initialisation
function if they need variables like this.
* Emit dynamic initialisers for these variables in the compiler, called from
the .init_array section (as is currently done for C++ dynamic initialisers).
We have a patch to do this, described in my original RFC email
(http://lists.llvm.org/pipermail/llvm-dev/2015-December/093022.html), but the
feedback from that RFC thread was that this is not something that belongs in
clang.
* Use a small dynamic loader to fix up these variables, by adding the
difference between the load and execution address of the relevant section.
This would require linker co-operation to generate a table of addresses that
need fixing up.
Differential Revision: https://reviews.llvm.org/D23196
llvm-svn: 278016
Summary:
This patch prevents OpenMP flags from being forwarded to CUDA device commands. That was causing the CUDA frontend to attempt to emit OpenMP code which is not supported.
This fixes the bug reported in https://llvm.org/bugs/show_bug.cgi?id=28723.
Reviewers: hfinkel, carlo.bertolli, arpith-jacob, kkwli0, tra, ABataev
Subscribers: caomhin, cfe-commits
Differential Revision: https://reviews.llvm.org/D22895
llvm-svn: 276979
This resubmit r270688 which broke some specific buildbots.That's because
there is incorrect indexing problem in the targetparser,and the problem is
fixed in r276957.
Differential Revision: https://reviews.llvm.org/D21277
llvm-svn: 276958
Compute an effective triple once per job. Cache the triple in the
prevailing ToolChain for the duration of the job.
Clients which need effective triples now look them up in the ToolChain.
This eliminates wasteful re-computation of effective triples (e.g in
getARMFloatABI()).
While we're at it, delete MachO::ComputeEffectiveClangTriple. It was a
no-op override.
Differential Revision: https://reviews.llvm.org/D22596
llvm-svn: 276937
This reverts commit r275895 in order to address some post-commit review
feedback from Eric Christopher (see: the list thread for r275895).
llvm-svn: 276936
Summary:
This patch aims at removing redundancy in the way include paths for the regular and offloading toolchains are appended to the arguments list in the clang tool.
This was suggested by @rsmith in response to r275931.
Reviewers: rsmith, tra
Subscribers: rsmith, cfe-commits
Differential Revision: https://reviews.llvm.org/D22518
llvm-svn: 276929
Make integers explicitly unsigned, so the tuple constructor will resolve
properly when but with clang 3.6, 3.7 and gcc 6.1.1 libstdc++ headers.
Patch by Frederich Munch!
Differential Revision: https://reviews.llvm.org/D22798
llvm-svn: 276831
Summary:
This patch adds clang system include path when offloading tool chains, e.g. CUDA, are used in the current compilation.
This fixes an issue detected by @rsmith in response to r275645.
Reviewers: rsmith, tra
Subscribers: rsmith, cfe-commits
Differential Revision: https://reviews.llvm.org/D22490
llvm-svn: 275931
Compute an effective target triple exactly once in ConstructJob(), and
then simply pass around references to it. This eliminates wasteful
re-computation of effective triples (e.g in getARMFloatABI()).
Differential Revision: https://reviews.llvm.org/D22290
llvm-svn: 275895
For assembly files without .intel_syntax or .att_syntax directives, allow the
-masm= flag to supply a default assembly dialect. For example,
C:\TMP> type intel.s
.text
mov al,0
C:\TMP> clang -masm=intel -c intel.s
Without this patch, one would need to pass an "-mllvm -x86-asm-syntax=" flag
directly to the backend.
C:\TMP> clang -mllvm --x86-asm-syntax=intel -c intel.s
Differentials Review: http://reviews.llvm.org/D22285
llvm-svn: 275877
Summary:
This patch replaces the CUDA specific action by a generic offload action. The offload action may have multiple dependences classier in “host” and “device”. The way this generic offloading action is used is very similar to what is done today by the CUDA implementation: it is used to set a specific toolchain and architecture to its dependences during the generation of jobs.
This patch also proposes propagating the offloading information through the action graph so that that information can be easily retrieved at any time during the generation of commands. This allows e.g. the "clang tool” to evaluate whether CUDA should be supported for the device or host and ptas to easily retrieve the target architecture.
This is an example of how the action graphs would look like (compilation of a single CUDA file with two GPU architectures)
```
0: input, "cudatests.cu", cuda, (host-cuda)
1: preprocessor, {0}, cuda-cpp-output, (host-cuda)
2: compiler, {1}, ir, (host-cuda)
3: input, "cudatests.cu", cuda, (device-cuda, sm_35)
4: preprocessor, {3}, cuda-cpp-output, (device-cuda, sm_35)
5: compiler, {4}, ir, (device-cuda, sm_35)
6: backend, {5}, assembler, (device-cuda, sm_35)
7: assembler, {6}, object, (device-cuda, sm_35)
8: offload, "device-cuda (nvptx64-nvidia-cuda:sm_35)" {7}, object
9: offload, "device-cuda (nvptx64-nvidia-cuda:sm_35)" {6}, assembler
10: input, "cudatests.cu", cuda, (device-cuda, sm_37)
11: preprocessor, {10}, cuda-cpp-output, (device-cuda, sm_37)
12: compiler, {11}, ir, (device-cuda, sm_37)
13: backend, {12}, assembler, (device-cuda, sm_37)
14: assembler, {13}, object, (device-cuda, sm_37)
15: offload, "device-cuda (nvptx64-nvidia-cuda:sm_37)" {14}, object
16: offload, "device-cuda (nvptx64-nvidia-cuda:sm_37)" {13}, assembler
17: linker, {8, 9, 15, 16}, cuda-fatbin, (device-cuda)
18: offload, "host-cuda (powerpc64le-unknown-linux-gnu)" {2}, "device-cuda (nvptx64-nvidia-cuda)" {17}, ir
19: backend, {18}, assembler
20: assembler, {19}, object
21: input, "cuda", object
22: input, "cudart", object
23: linker, {20, 21, 22}, image
```
The changes in this patch pass the existent regression tests (keeps the existent functionality) and resulting binaries execute correctly in a Power8+K40 machine.
Reviewers: echristo, hfinkel, jlebar, ABataev, tra
Subscribers: guansong, andreybokhanko, tcramer, mkuron, cfe-commits, arpith-jacob, carlo.bertolli, caomhin
Differential Revision: https://reviews.llvm.org/D18171
llvm-svn: 275645
Summary: Fix the build to use hasFlag instead of hasArg for checking some flags.
Reviewers: echristo
Subscribers: mehdi_amini, cfe-commits
Differential Revision: http://reviews.llvm.org/D22338
llvm-svn: 275377
Summary:
Depends on D21982 which implements the in-memory logging implementation of the
XRay runtime. These additional changes also depends on D20352 which adds the
bulk of XRay flags/dependencies when using the `-fxray-instrument` flag from
Clang.
Reviewers: echristo, rnk, aaron.ballman
Subscribers: mehdi_amini, cfe-commits
Differential Revision: http://reviews.llvm.org/D21983
llvm-svn: 275368
-fxray-instrument: enables XRay annotation of IR
-fxray-instruction-threshold: configures the threshold for function size (looking at IR instructions), and allow LLVM to decide whether to add the nop sleds later on in the process.
Also implements the related xray_always_instrument and xray_never_instrument function attributes.
Patch by Dean Michael Berris.
llvm-svn: 275330
MASM (ML.exe and ML64.exe) and older versions of MSVC (CL.exe) support a
flag called /Zd which is more-or-less -gline-tables-only.
It seems nicer to support this flag instead of exposing
-gline-tables-only.
llvm-svn: 274991
Add OCL option -cl-no-signed-zeros to driver options.
Also added to opencl.cl testcases.
Patch by Aaron En Ye Shi.
Differential Revision: http://reviews.llvm.org/D22067
llvm-svn: 274923
Summary:
Raise an error if you're using a CUDA installation that's too old for
the requested architectures. In practice, this means that you need a
CUDA 8 install to compile for sm_6*.
Reviewers: tra
Subscribers: cfe-commits
Differential Revision: http://reviews.llvm.org/D21869
llvm-svn: 274781
Summary:
Currently our handling of CUDA architectures is scattered all around
clang. This patch centralizes it.
A key advantage of this centralization is that you can now write a C++
switch on e.g. CudaArch and get a compile error if you don't handle one
of the enum values.
Reviewers: tra
Subscribers: cfe-commits
Differential Revision: http://reviews.llvm.org/D21867
llvm-svn: 274681
Summary: This change exposes the recently added LEON CPUs (D19359) in the LLVM Sparc backend to Clang, allowing the cpu's to be selected using the -mcpu flag.
Reviewers: jyknight, lero_chris
Subscribers: jyknight, cfe-commits
Differential Revision: http://reviews.llvm.org/D21683
llvm-svn: 274487
Allow -cl-std and other standard -cl- options from cc1 to driver.
Added a test for the options moved.
Patch by Aaron En Ye Shi.
Differential Revision: http://reviews.llvm.org/D21031
llvm-svn: 274150
The PIC and PIE levels are not independent. In fact, if PIE is defined
it is always the same as PIC.
This is clear in the driver where ParsePICArgs returns a PIC level and
a IsPIE boolean. Unfortunately that is currently lost and we pass two
redundant levels down the pipeline.
This patch keeps a bool and a PIC level all the way down to codegen.
llvm-svn: 273566
Add support for /Ob1 (and equivalent -finline-hint-functions), which enable
inlining only for functions marked inline, either explicitly (via inline
keyword, for example), or implicitly (function definition in class body,
for example).
This works by enabling inlining pass, and adding noinline attribute to
every function not marked inline.
Patch by Rudy Pons <rudy.pons@ilod.org>!
Differential Revision: http://reviews.llvm.org/D20647
llvm-svn: 273440
Add -mno-iamcu option to:
1) Countervail -miamcu option easily
2) Be compatible with GCC which supports this option
Differential Revision: http://reviews.llvm.org/D21469
llvm-svn: 273147
This mirrors the many other -i*after options to insert a new system search
directory at the end of the search path. This makes it possible to actually
inject a search path after the resource dir. This option is similar in spirit
to the /imsvc option in the clang-cl driver. This is needed to properly use the
driver for Windows targets where the clang headers wrap some of the system
headers.
This concept is actually useful on other targets (e.g. Linux) and would be
really easy to support on the core toolchain.
llvm-svn: 273016
This is the last patch required to support compilation for Intel MCU target (e.g. Intel(R) Quark(TM) micro controller D 2000).
When IAMCU triple is used:
* Use IAMCU linker output format
* Link with IAMCU crt objects
* Link with IAMCU libraries
Differential Revision: http://reviews.llvm.org/D20675
llvm-svn: 272885
This is the second patch required to support compilation for Intel MCU target (e.g. Intel(R) Quark(TM) micro controller D 2000).
When IAMCU triple is used:
* Recognize and use IAMCU GCC toolchain
* Set up include paths
* Forbid C++
Differential Revision: http://reviews.llvm.org/D19274
llvm-svn: 272883
Summary:
This patch introduces the concept of offloading tool chain and offloading kind. Each tool chain may have associated an offloading kind that marks it as used in a given programming model that requires offloading.
It also adds the logic to iterate on the tool chains based on the kind. Currently, only CUDA is supported, but in general a programming model (an offloading kind) may have associated multiple tool chains that require supporting offloading.
This patch does not add tests - its goal is to keep the existing functionality.
This patch is the first of a series of three that attempts to make the current support of CUDA more generic and easier to extend to other programming models, namely OpenMP. It tries to capture the suggestions/improvements/concerns on the initial proposal in http://lists.llvm.org/pipermail/cfe-dev/2016-February/047547.html. It only tackles the more consensual part of the proposal, i.e.does not address the problem of intermediate files bundling yet.
Reviewers: ABataev, jlebar, echristo, hfinkel, tra
Subscribers: guansong, Hahnfeld, andreybokhanko, tcramer, mkuron, cfe-commits, arpith-jacob, carlo.bertolli, caomhin
Differential Revision: http://reviews.llvm.org/D18170
llvm-svn: 272571
