Revert "[ThinLTO] Clang side of renaming of function index (NFC)"

This reverts commit r263491. Missed a file on the LLVM side.

llvm-svn: 263494

[ThinLTO] Clang side of renaming of function index (NFC)

This is the companion to an LLVM patch that renamed the function index
data structures and files to use the more general module summary index

[ThinLTO] Clang side of renaming of function index (NFC)

This is the companion to an LLVM patch that renamed the function index
data structures and files to use the more general module summary index.

llvm-svn: 263491

show more ...

[OpenMP] Replace offloading option that start with -o with -fo.

Summary:
The current offloading implementation is using -omptargets and -omp-host-ir-file-path options in the frontend. This causes th

[OpenMP] Replace offloading option that start with -o with -fo.

Summary:
The current offloading implementation is using -omptargets and -omp-host-ir-file-path options in the frontend. This causes the user a lot of trouble due to to the conflicts with the -o option. E.g. if the user misspells omptargets he will end up with a file with a weird name.

This patches replaces these two options with -fomptargets and -fomp-host-ir-file-path to avoid these issues, and it is also more consistent with the other options like -fopenmp.

Reviewers: hfinkel, carlo.bertolli, arpith-jacob, kkwli0, ABataev

Subscribers: cfe-commits, caomhin, fraggamuffin

Differential Revision: http://reviews.llvm.org/D18112

llvm-svn: 263442

show more ...

[Frontend] Disable value name discarding for all sanitizers.

ASan also relies on names on allocas and will emit unhelpful output if
they're not present. Just force-enable value names for now. Should

[Frontend] Disable value name discarding for all sanitizers.

ASan also relies on names on allocas and will emit unhelpful output if
they're not present. Just force-enable value names for now. Should
unbreak release builds of asan.

llvm-svn: 263429

show more ...

Temporarily make discard value names depend on whether or not we're
trying to track origins in the memory sanitizer since the backend
instrumentation pass currently takes names from the Instruction.

Temporarily make discard value names depend on whether or not we're
trying to track origins in the memory sanitizer since the backend
instrumentation pass currently takes names from the Instruction.

Fixes all of the origin tracking tests in compiler-rt after the
-discard-value-name option was added.

llvm-svn: 263412

show more ...

Remove compile time PreserveName in favor of a runtime cc1 -discard-value-names option

Summary:
This flag is enabled by default in the driver when NDEBUG is set. It
is forwarded on the LLVMContext t

Remove compile time PreserveName in favor of a runtime cc1 -discard-value-names option

Summary:
This flag is enabled by default in the driver when NDEBUG is set. It
is forwarded on the LLVMContext to discard all value names (but
GlobalValue) for performance purpose.

This an improved version of D18024

Reviewers: echristo, chandlerc

Subscribers: cfe-commits

Differential Revision: http://reviews.llvm.org/D18127

From: Mehdi Amini <mehdi.amini@apple.com>
llvm-svn: 263394

show more ...

[PGO] Change profile use cc1 option to handle IR level profiles

This patch changes cc1 option for PGO profile use from
-fprofile-instr-use=<path> to -fprofile-instrument-use-path=<path>.
-fprofile-i

[PGO] Change profile use cc1 option to handle IR level profiles

This patch changes cc1 option for PGO profile use from
-fprofile-instr-use=<path> to -fprofile-instrument-use-path=<path>.
-fprofile-instr-use=<path> is now a driver only option.

In addition to decouple the cc1 option from the driver level option, this patch
also enables IR level profile use. cc1 option handling now reads the profile
header and sets CodeGenOpt ProfileUse (valid values are {None, Clang, LLVM}
-- this is a common enum for -fprofile-instrument={}, for the profile
instrumentation), and invoke the pipeline to enable the respective PGO use pass.

Reviewers: silvas, davidxl

Differential Revision: http://reviews.llvm.org/D17737

llvm-svn: 262515

show more ...

clang-cl: Implement initial limited support for precompiled headers.

In the gcc precompiled header model, one explicitly runs clang with `-x
c++-header` on a .h file to produce a gch file, and then

clang-cl: Implement initial limited support for precompiled headers.

In the gcc precompiled header model, one explicitly runs clang with `-x
c++-header` on a .h file to produce a gch file, and then includes the header
with `-include foo.h` and if a .gch file exists for that header it gets used.
This is documented at
http://clang.llvm.org/docs/UsersManual.html#precompiled-headers

cl.exe's model is fairly different, and controlled by the two flags /Yc and
/Yu. A pch file is generated as a side effect of a regular compilation when
/Ycheader.h is passed. While the compilation is running, the compiler keeps
track of #include lines in the main translation unit and writes everything up
to an `#include "header.h"` line into a pch file. Conversely, /Yuheader.h tells
the compiler to skip all code in the main TU up to and including `#include
"header.h"` and instead load header.pch. (It's also possible to use /Yc and /Yu
without an argument, in that case a `#pragma hrdstop` takes the role of
controlling the point where pch ends and real code begins.)

This patch implements limited support for this in that it requires the pch
header to be passed as a /FI force include flag – with this restriction,
it can be implemented almost completely in the driver with fairly small amounts
of code. For /Yu, this is trivial, and for /Yc a separate pch action is added
that runs before the actual compilation. After r261774, the first failing
command makes a compilation stop – this means if the pch fails to build the
main compilation won't run, which is what we want. However, in /fallback builds
we need to run the main compilation even if the pch build fails so that the
main compilation's fallback can run. To achieve this, add a ForceSuccessCommand
that pretends that the pch build always succeeded in /fallback builds (the main
compilation will then fail to open the pch and run the fallback cl.exe
invocation).

If /Yc /Yu are used in a setup that clang-cl doesn't implement yet, clang-cl
will now emit a "not implemented yet; flag ignored" warning that can be
disabled using -Wno-clang-cl-pch.

Since clang-cl doesn't yet serialize some important things (most notably
`pragma comment(lib, ...)`, this feature is disabled by default and only
enabled by an internal driver flag. Once it's more stable, this internal flag
will disappear.

(The default stdafx.h setup passes stdafx.h as explicit argument to /Yc but not
as /FI – instead every single TU has to `#include <stdafx.h>` as first thing it
does. Implementing support for this should be possible with the approach in
this patch with minimal frontend changes by passing a --stop-at / --start-at
flag from the driver to the frontend. This is left for a follow-up. I don't
think we ever want to support `#pragma hdrstop`, and supporting it with this
approach isn't easy: This approach relies on the driver knowing the pch
filename in advance, and `#pragma hdrstop(out.pch)` can set the output
filename, so the driver can't know about it in advance.)

clang-cl now also honors /Fp and puts pch files in the same spot that cl.exe
would put them, but the pch file format is of course incompatible. This has
ramifications on /fallback, so /Yc /Yu aren't passed through to cl.exe in
/fallback builds.

http://reviews.llvm.org/D17695

llvm-svn: 262420

show more ...

[PGO] clang cc1 option change to enable IR level instrumentation

This patch expands cc1 option -fprofile-instrument= with a new value: -fprofile-instrument=llvm
which enables IR level PGO instrument

[PGO] clang cc1 option change to enable IR level instrumentation

This patch expands cc1 option -fprofile-instrument= with a new value: -fprofile-instrument=llvm
which enables IR level PGO instrumentation.

Reviewers: davidxl, silvas

Differential Revision: http://reviews.llvm.org/D17622

llvm-svn: 262239

show more ...

Add whole-program vtable optimization feature to Clang.

This patch introduces the -fwhole-program-vtables flag, which enables the
whole-program vtable optimization feature (D16795) in Clang.

Differ

Add whole-program vtable optimization feature to Clang.

This patch introduces the -fwhole-program-vtables flag, which enables the
whole-program vtable optimization feature (D16795) in Clang.

Differential Revision: http://reviews.llvm.org/D16821

llvm-svn: 261767

show more ...

Revert "[VFS] Add 'overlay-relative' field to YAML files" and "[VFS] Fix call to getVFSFromYAML in unittests"

This reverts commit r261552 and r261556 because of failing unittests on
windows:

Failin

Revert "[VFS] Add 'overlay-relative' field to YAML files" and "[VFS] Fix call to getVFSFromYAML in unittests"

This reverts commit r261552 and r261556 because of failing unittests on
windows:

Failing Tests (4):
Clang-Unit :: Basic/BasicTests.exe/VFSFromYAMLTest.CaseInsensitive
Clang-Unit :: Basic/BasicTests.exe/VFSFromYAMLTest.DirectoryIteration
Clang-Unit :: Basic/BasicTests.exe/VFSFromYAMLTest.MappedFiles
Clang-Unit :: Basic/BasicTests.exe/VFSFromYAMLTest.UseExternalName

llvm-svn: 261613

show more ...

[VFS] Add 'overlay-relative' field to YAML files

The VFS overlay mapping between virtual paths and real paths is done through
the 'external-contents' entries in YAML files, which contains hardcoded

[VFS] Add 'overlay-relative' field to YAML files

The VFS overlay mapping between virtual paths and real paths is done through
the 'external-contents' entries in YAML files, which contains hardcoded paths
to the real files.

When a module compilation crashes, headers are dumped into <name>.cache/vfs
directory and are mapped via the <name>.cache/vfs/vfs.yaml. The script
generated for reproduction uses -ivfsoverlay pointing to file to gather the
mapping between virtual paths and files inside <name>.cache/vfs. Currently, we
are only capable of reproducing such crashes in the same machine as they
happen, because of the hardcoded paths in 'external-contents'.

To be able to reproduce a crash in another machine, this patch introduces a new
option in the VFS yaml file called 'overlay-relative'. When it's equal to
'true' it means that the provided path to the YAML file through the
-ivfsoverlay option should also be used to prefix the final path for every
'external-contents'.

Example, given the invocation snippet "... -ivfsoverlay
<name>.cache/vfs/vfs.yaml" and the following entry in the yaml file:

"overlay-relative": "true",
"roots": [
...
"type": "directory",
"name": "/usr/include",
"contents": [
{
"type": "file",
"name": "stdio.h",
"external-contents": "/usr/include/stdio.h"
},
...

Here, a file manager request for virtual "/usr/include/stdio.h", that will map
into real path "/<absolute_path_to>/<name>.cache/vfs/usr/include/stdio.h.

This is a useful feature for debugging module crashes in machines other than
the one where the error happened.

Differential Revision: http://reviews.llvm.org/D17457

rdar://problem/24499339

llvm-svn: 261552

show more ...

[MSVC Compat] Implement -EHc semantics

The -EHc flag implicitly adds a nothrow attribute to any extern "C"
function when exceptions are enabled.

llvm-svn: 261425

[modules] Flatten -fmodule-name= and -fmodule-implementation-of= into a single
option. Previously these options could both be used to specify that you were
compiling the implementation file of a modu

[modules] Flatten -fmodule-name= and -fmodule-implementation-of= into a single
option. Previously these options could both be used to specify that you were
compiling the implementation file of a module, with a different set of minor
bugs in each case.

This change removes -fmodule-implementation-of, and instead tracks a flag to
determine whether we're currently building a module. -fmodule-name now behaves
the same way that -fmodule-implementation-of previously did.

llvm-svn: 261372

show more ...

[sanitizer-coverage] implement -fsanitize-coverage=trace-pc. This is similar to trace-bb, but has a different API. We already use the equivalent flag in GCC for Linux kernel fuzzing. We may be able t

[sanitizer-coverage] implement -fsanitize-coverage=trace-pc. This is similar to trace-bb, but has a different API. We already use the equivalent flag in GCC for Linux kernel fuzzing. We may be able to use this flag with AFL too

llvm-svn: 261159

show more ...

Re-apply for the 2nd-time r259977 - [OpenMP] Reorganize code to allow specialized code generation for different devices.

This was reverted by r260036, but was not the cause of the problem in the bui

Re-apply for the 2nd-time r259977 - [OpenMP] Reorganize code to allow specialized code generation for different devices.

This was reverted by r260036, but was not the cause of the problem in the buildbot.

llvm-svn: 260106

show more ...

Revert "Re-apply r259977 - [OpenMP] Reorganize code to allow specialized code generation for different devices."

This reverts commit r259985, as it still fails one buildbot.

llvm-svn: 260036

Re-apply r259977 - [OpenMP] Reorganize code to allow specialized code generation for different devices.

This was reverted due to a failure in a buildbot, but it turned out the failure was unrelated.

Re-apply r259977 - [OpenMP] Reorganize code to allow specialized code generation for different devices.

This was reverted due to a failure in a buildbot, but it turned out the failure was unrelated.

llvm-svn: 259985

show more ...

Revert r259977 - [OpenMP] Reorganize code to allow specialized code generation for different devices.

It triggered some problem in the configuration related with zlib and exposed in the driver.

llv

Revert r259977 - [OpenMP] Reorganize code to allow specialized code generation for different devices.

It triggered some problem in the configuration related with zlib and exposed in the driver.

llvm-svn: 259984

show more ...

[OpenMP] Reorganize code to allow specialized code generation for different devices.

Summary:
Different devices may in some cases require different code generation schemes in order to implement Open

[OpenMP] Reorganize code to allow specialized code generation for different devices.

Summary:
Different devices may in some cases require different code generation schemes in order to implement OpenMP. This is required not only for performance reasons, but also because it may not be possible to have the current (default) implementation working for these devices. E.g. GPU's cannot implement the same scheme a target such as powerpc or x86b would use, in the sense that it does not have the ability to fork threads, instead all the threads are always executing and need to be managed by the implementation.

This patch proposes a reorganization of the code in the OpenMP code generation to pave the way to have specialized implementation of OpenMP support. More than a "real" patch this is more a request for comments in order to understand if what is proposed is acceptable or if there are better/easier ways to do it.

In this patch part of the common OpenMP codegen infrastructure is moved to a new file under a new namespace (CGOpenMPCommon) so it can be shared between the default implementation and the specialized one. When CGOpenMPRuntime is created, an attempt to select a specialized implementation is done.

In the patch a specialization for nvptx targets is done which currently checks if the target is an OpenMP device and trap if it is not.

Let me know comments suggestions you may have.

Reviewers: hfinkel, carlo.bertolli, arpith-jacob, kkwli0, ABataev

Subscribers: Hahnfeld, cfe-commits, fraggamuffin, caomhin, jholewinski

Differential Revision: http://reviews.llvm.org/D16784

llvm-svn: 259977

show more ...

Eliminate an unnecessary enum, use the LLVM version. NFC

llvm-svn: 259950

[PGO] cc1 option name change for profile instrumentation

This patch changes cc1 option -fprofile-instr-generate to an enum option
-fprofile-instrument={clang|none}. It also changes cc1 options
-fpro

[PGO] cc1 option name change for profile instrumentation

This patch changes cc1 option -fprofile-instr-generate to an enum option
-fprofile-instrument={clang|none}. It also changes cc1 options
-fprofile-instr-generate= to -fprofile-instrument-path=.
The driver level option -fprofile-instr-generate and -fprofile-instr-generate=
remain intact. This change will pave the way to integrate new PGO
instrumentation in IR level.

Review: http://reviews.llvm.org/D16730
llvm-svn: 259811

show more ...

Move DebugInfoKind into its own header to cut the cyclic dependency edge from Driver to Frontend.

llvm-svn: 259489

Do not define GXX_RTTI macro for C.
This is same as GCC behavior (tested with GCC 4.8.2).

Differential Revision: http://reviews.llvm.org/D16365

llvm-svn: 258850

[CUDA] Add -fcuda-allow-variadic-functions.

Summary:
Turns out the variadic function checking added in r258643 was too strict
for some existing users; give them an escape valve. When
-fcuda-allow-v

[CUDA] Add -fcuda-allow-variadic-functions.

Summary:
Turns out the variadic function checking added in r258643 was too strict
for some existing users; give them an escape valve. When
-fcuda-allow-variadic-functions is passed, the front-end makes no
attempt to disallow C-style variadic functions. Calls to va_arg are
still not allowed.

Reviewers: tra

Subscribers: cfe-commits, jhen, echristo, bkramer

Differential Revision: http://reviews.llvm.org/D16559

llvm-svn: 258822

show more ...