Driver,CodeGen: introduce support for Swift CFString layout

Add a new driver level flag `-fcf-runtime-abi=` that allows one to specify the
runtime ABI for CoreFoundation. This controls the language

Driver,CodeGen: introduce support for Swift CFString layout

Add a new driver level flag `-fcf-runtime-abi=` that allows one to specify the
runtime ABI for CoreFoundation. This controls the language interoperability.
In particular, this is relevant for generating the CFConstantString classes
(primarily through the `__builtin___CFStringMakeConstantString` builtin) which
construct a reference to the "CFObject"'s `isa` field. This type differs
between swift 4.1 and 4.2+.

Valid values for the new option include:
- objc [default behaviour] - enable ObjectiveC interoperability
- swift-4.1 - enable interoperability with swift 4.1
- swift-4.2 - enable interoperability with swift 4.2
- swift-5.0 - enable interoperability with swift 5.0
- swift [alias] - target the latest swift ABI

Furthermore, swift 4.2+ changed the layout for the CFString when building
CoreFoundation *without* ObjectiveC interoperability. In such a case, a field
was added to the CFObject base type changing it from: <{ const int*, int }> to
<{ uintptr_t, uintptr_t, uint64_t }>.

In swift 5.0, the CFString type will be further adjusted to change the length
from a uint32_t on everything but BE LP64 targets to uint64_t.

Note that the default behaviour for clang remains unchanged and the new layout
must be explicitly opted into via `-fcf-runtime-abi=swift*`.

llvm-svn: 345222

show more ...

Add support for -mno-tls-direct-seg-refs to Clang

This patch exposes functionality added in rL344723 to the Clang driver/frontend
as a flag and adds appropriate metadata.

Driver tests pass:
```
nin

Add support for -mno-tls-direct-seg-refs to Clang

This patch exposes functionality added in rL344723 to the Clang driver/frontend
as a flag and adds appropriate metadata.

Driver tests pass:
```
ninja check-clang-driver
-snip-
Expected Passes : 472
Expected Failures : 3
Unsupported Tests : 65
```

Odd failure in CodeGen tests but unrelated to this:
```
ninja check-clang-codegen
-snip-
/SourceCache/llvm-trunk-8.0/tools/clang/test/CodeGen/builtins-wasm.c:87:10:
error: cannot compile this builtin function yet
-snip-
Failing Tests (1):
Clang :: CodeGen/builtins-wasm.c

Expected Passes : 1250
Expected Failures : 2
Unsupported Tests : 120
Unexpected Failures: 1
```

Original commit:
[X86] Support for the mno-tls-direct-seg-refs flag
Allows to disable direct TLS segment access (%fs or %gs). GCC supports a
similar flag, it can be useful in some circumstances, e.g. when a thread
context block needs to be updated directly from user space. More info and
specific use cases: https://bugs.llvm.org/show_bug.cgi?id=16145

Patch by nruslan (Ruslan Nikolaev).

Differential Revision: https://reviews.llvm.org/D53102

llvm-svn: 344739

show more ...

Add a flag to remap manglings when reading profile data information.

This can be used to preserve profiling information across codebase
changes that have widespread impact on mangled names, but acro

Add a flag to remap manglings when reading profile data information.

This can be used to preserve profiling information across codebase
changes that have widespread impact on mangled names, but across which
most profiling data should still be usable. For example, when switching
from libstdc++ to libc++, or from the old libstdc++ ABI to the new ABI,
or even from a 32-bit to a 64-bit build.

The user can provide a remapping file specifying parts of mangled names
that should be treated as equivalent (eg, std::__1 should be treated as
equivalent to std::__cxx11), and profile data will be treated as
applying to a particular function if its name is equivalent to the name
of a function in the profile data under the provided equivalences. See
the documentation change for a description of how this is configured.

Remapping is supported for both sample-based profiling and instruction
profiling. We do not support remapping indirect branch target
information, but all other profile data should be remapped
appropriately.

Support is only added for the new pass manager. If someone wants to also
add support for this for the old pass manager, doing so should be
straightforward.

llvm-svn: 344199

show more ...

Lift VFS from clang to llvm (NFC)

This patch moves the virtual file system form clang to llvm so it can be
used by more projects.

Concretely the patch:
- Moves VirtualFileSystem.{h|cpp} from clang

Lift VFS from clang to llvm (NFC)

This patch moves the virtual file system form clang to llvm so it can be
used by more projects.

Concretely the patch:
- Moves VirtualFileSystem.{h|cpp} from clang/Basic to llvm/Support.
- Moves the corresponding unit test from clang to llvm.
- Moves the vfs namespace from clang::vfs to llvm::vfs.
- Formats the lines affected by this change, mostly this is the result of
the added llvm namespace.

RFC on the mailing list:
http://lists.llvm.org/pipermail/llvm-dev/2018-October/126657.html

Differential revision: https://reviews.llvm.org/D52783

llvm-svn: 344140

show more ...

Introduce code_model macros

Summary:
gcc defines macros such as __code_model_small_ based on the user passed command line flag -mcmodel. clang accepts a flag with the same name and similar effects,

Introduce code_model macros

Summary:
gcc defines macros such as __code_model_small_ based on the user passed command line flag -mcmodel. clang accepts a flag with the same name and similar effects, but does not generate any macro that the user can use. This cl narrows the gap between gcc and clang behaviour.

However, achieving full compatibility with gcc is not trivial: The set of valid values for mcmodel in gcc and clang are not equal. Also, gcc defines different macros for different architectures. In this cl, we only tackle an easy part of the problem and define the macro only for x64 architecture. When the user does not specify a mcmodel, the macro for small code model is produced, as is the case with gcc.

Reviewers: compnerd, MaskRay

Reviewed By: MaskRay

Subscribers: cfe-commits

Tags: #clang

Differential Revision: https://reviews.llvm.org/D52920

llvm-svn: 344000

show more ...

[Frontend] Delete -print-decl-contexts

Summary: Its job is covered by -ast-dump. The option is rarely used and lacks many AST nodes which will lead to llvm_unreachable() crash.

Reviewers: rsmith, a

[Frontend] Delete -print-decl-contexts

Summary: Its job is covered by -ast-dump. The option is rarely used and lacks many AST nodes which will lead to llvm_unreachable() crash.

Reviewers: rsmith, arphaman

Reviewed By: rsmith

Subscribers: jfb, cfe-commits

Differential Revision: https://reviews.llvm.org/D52529

llvm-svn: 343660

show more ...

[HIP] Support early finalization of device code for -fno-gpu-rdc

This patch renames -f{no-}cuda-rdc to -f{no-}gpu-rdc and keeps the original
options as aliases. When -fgpu-rdc is off,
clang will ass

[HIP] Support early finalization of device code for -fno-gpu-rdc

This patch renames -f{no-}cuda-rdc to -f{no-}gpu-rdc and keeps the original
options as aliases. When -fgpu-rdc is off,
clang will assume the device code in each translation unit does not call
external functions except those in the device library, therefore it is possible
to compile the device code in each translation unit to self-contained kernels
and embed them in the host object, so that the host object behaves like
usual host object which can be linked by lld.

The benefits of this feature is: 1. allow users to create static libraries which
can be linked by host linker; 2. amortized device code linking time.

This patch modifies HIP action builder to insert actions for linking device
code and generating HIP fatbin, and pass HIP fatbin to host backend action.
It extracts code for constructing command for generating HIP fatbin as
a function so that it can be reused by early finalization. It also modifies
codegen of HIP host constructor functions to embed the device fatbin
when it is available.

Differential Revision: https://reviews.llvm.org/D52377

llvm-svn: 343611

show more ...

Use the container form llvm::sort(C, ...)

There are a few leftovers of rC343147 that are not (\w+)\.begin but in
the form of ([-[:alnum:]>.]+)\.begin or spanning two lines. Change them
to use the co

Use the container form llvm::sort(C, ...)

There are a few leftovers of rC343147 that are not (\w+)\.begin but in
the form of ([-[:alnum:]>.]+)\.begin or spanning two lines. Change them
to use the container form in this commit. The 12 occurrences have been
inspected manually for safety.

llvm-svn: 343425

show more ...

[analyzer] Provide an option to dump generated exploded graphs to a given file.

Dumping graphs instead of opening them is often very useful,
e.g. for transfer or converting to SVG.

Basic sanity che

[analyzer] Provide an option to dump generated exploded graphs to a given file.

Dumping graphs instead of opening them is often very useful,
e.g. for transfer or converting to SVG.

Basic sanity check for generated exploded graphs.

Differential Revision: https://reviews.llvm.org/D52637

llvm-svn: 343352

show more ...

[modules] Frontend support for building a header module from a list of
headaer files.

llvm-svn: 342304

[clang-cl, PCH] Support for /Yc and /Yu without filename and #pragma hdrstop

With clang-cl, when the user specifies /Yc or /Yu without a filename
the compiler uses a #pragma hdrstop in the main sour

[clang-cl, PCH] Support for /Yc and /Yu without filename and #pragma hdrstop

With clang-cl, when the user specifies /Yc or /Yu without a filename
the compiler uses a #pragma hdrstop in the main source file to
determine the end of the PCH. If a header is specified with /Yc or
/Yu #pragma hdrstop has no effect.

The optional #pragma hdrstop filename argument is not yet supported.

Differential Revision: https://reviews.llvm.org/D51391

llvm-svn: 341963

show more ...

Revert "[OPENMP][NVPTX] Disable runtime-type info for CUDA devices."

Still need the RTTI for NVPTX target to pass sema checks.

llvm-svn: 341668

[MSan] add KMSAN support to Clang driver

Boilerplate code for using KMSAN instrumentation in Clang.

We add a new command line flag, -fsanitize=kernel-memory, with a
corresponding SanitizerKind::Ker

[MSan] add KMSAN support to Clang driver

Boilerplate code for using KMSAN instrumentation in Clang.

We add a new command line flag, -fsanitize=kernel-memory, with a
corresponding SanitizerKind::KernelMemory, which, along with
SanitizerKind::Memory, maps to the memory_sanitizer feature.

KMSAN is only supported on x86_64 Linux.

It's incompatible with other sanitizers, but supports code coverage
instrumentation.

llvm-svn: 341641

show more ...

[analyzer] Remove traces of ubigraph visualization

Ubigraph project has been dead since about 2008, and to the best of my
knowledge, no one was using it.
Previously, I wasn't able to launch the exis

[analyzer] Remove traces of ubigraph visualization

Ubigraph project has been dead since about 2008, and to the best of my
knowledge, no one was using it.
Previously, I wasn't able to launch the existing binary at all.

Differential Revision: https://reviews.llvm.org/D51655

llvm-svn: 341601

show more ...

[OPENMP][NVPTX] Disable runtime-type info for CUDA devices.

RTTI is not supported by the NVPTX target.

llvm-svn: 341483

[x86/SLH] Add a real Clang flag and LLVM IR attribute for Speculative
Load Hardening.

Wires up the existing pass to work with a proper IR attribute rather
than just a hidden/internal flag. The inter

[x86/SLH] Add a real Clang flag and LLVM IR attribute for Speculative
Load Hardening.

Wires up the existing pass to work with a proper IR attribute rather
than just a hidden/internal flag. The internal flag continues to work
for now, but I'll likely remove it soon.

Most of the churn here is adding the IR attribute. I talked about this
Kristof Beyls and he seemed at least initially OK with this direction.
The idea of using a full attribute here is that we *do* expect at least
some forms of this for other architectures. There isn't anything
*inherently* x86-specific about this technique, just that we only have
an implementation for x86 at the moment.

While we could potentially expose this as a Clang-level attribute as
well, that seems like a good question to defer for the moment as it
isn't 100% clear whether that or some other programmer interface (or
both?) would be best. We'll defer the programmer interface side of this
for now, but at least get to the point where the feature can be enabled
without relying on implementation details.

This also allows us to do something that was really hard before: we can
enable *just* the indirect call retpolines when using SLH. For x86, we
don't have any other way to mitigate indirect calls. Other architectures
may take a different approach of course, and none of this is surfaced to
user-level flags.

Differential Revision: https://reviews.llvm.org/D51157

llvm-svn: 341363

show more ...

[DEBUGINFO] Add support for emission of the debug directives only.

Summary:
Added option -gline-directives-only to support emission of the debug directives
only. It behaves very similar to -gline-ta

[DEBUGINFO] Add support for emission of the debug directives only.

Summary:
Added option -gline-directives-only to support emission of the debug directives
only. It behaves very similar to -gline-tables-only, except that it sets
llvm debug info emission kind to
llvm::DICompileUnit::DebugDirectivesOnly.

Reviewers: echristo

Subscribers: aprantl, fedor.sergeev, JDevlieghere, cfe-commits

Differential Revision: https://reviews.llvm.org/D51177

llvm-svn: 341212

show more ...

[OPENMP][NVPTX] Add options -f[no-]openmp-cuda-force-full-runtime.

Added options -f[no-]openmp-cuda-force-full-runtime to [not] force use
of the full runtime for OpenMP offloading to CUDA devices.

[OPENMP][NVPTX] Add options -f[no-]openmp-cuda-force-full-runtime.

Added options -f[no-]openmp-cuda-force-full-runtime to [not] force use
of the full runtime for OpenMP offloading to CUDA devices.

llvm-svn: 341073

show more ...

[analyzer] Move analyzer-eagerly-assume to AnalyzerOptions, enable by default

Differential Revision: https://reviews.llvm.org/D51251

llvm-svn: 340963

Currently clang does not emit unused static constants. GCC emits these
constants by default when there is no optimization.

GCC's option -fno-keep-static-consts can be used to not emit
unused static

Currently clang does not emit unused static constants. GCC emits these
constants by default when there is no optimization.

GCC's option -fno-keep-static-consts can be used to not emit
unused static constants.

In Clang, since default behavior does not keep unused static constants,
-fkeep-static-consts can be used to emit these if required. This could be
useful for producing identification strings like SVN identifiers
inside the object file even though the string isn't used by the program.

Differential Revision: https://reviews.llvm.org/D40925

llvm-svn: 340439

show more ...

[AArch64] Add Tiny Code Model for AArch64

Adds a tiny code model to Clang along side rL340397.

Differential Revision: https://reviews.llvm.org/D49674

llvm-svn: 340398

Add a new flag and attributes to control static destructor registration

This commit adds the flag -fno-c++-static-destructors and the attributes
[[clang::no_destroy]] and [[clang::always_destroy]].

Add a new flag and attributes to control static destructor registration

This commit adds the flag -fno-c++-static-destructors and the attributes
[[clang::no_destroy]] and [[clang::always_destroy]]. no_destroy specifies that a
specific static or thread duration variable shouldn't have it's destructor
registered, and is the default in -fno-c++-static-destructors mode.
always_destroy is the opposite, and is the default in -fc++-static-destructors
mode.

A variable whose destructor is disabled (either because of
-fno-c++-static-destructors or [[clang::no_destroy]]) doesn't count as a use of
the destructor, so we don't do any access checking or mark it referenced. We
also don't emit -Wexit-time-destructors for these variables.

rdar://21734598

Differential revision: https://reviews.llvm.org/D50994

llvm-svn: 340306

show more ...

DebugInfo: Add the ability to disable DWARF name tables entirely

This changes the current default behavior (from emitting pubnames by
default, to not emitting them by default) & moves to matching GC

DebugInfo: Add the ability to disable DWARF name tables entirely

This changes the current default behavior (from emitting pubnames by
default, to not emitting them by default) & moves to matching GCC's
behavior* with one significant difference: -gno(-gnu)-pubnames disables
pubnames even in the presence of -gsplit-dwarf (though -gsplit-dwarf
still by default enables -ggnu-pubnames). This allows users to disable
pubnames (& the new DWARF5 accelerated access tables) when they might
not be worth the size overhead.

* GCC's behavior is that -ggnu-pubnames and -gpubnames override each
other, and that -gno-gnu-pubnames and -gno-pubnames act as synonyms and
disable either kind of pubnames if they come last. (eg: -gpubnames
-gno-gnu-pubnames causes no pubnames (neither gnu or standard) to be
emitted)

llvm-svn: 340206

show more ...

Rename -mlink-cuda-bitcode to -mlink-builtin-bitcode

The same semantics work for OpenCL, and probably any offload
language. Keep the old name around as an alias.

llvm-svn: 340193

[AArch64] - return address signing

- Add a command line options -msign-return-address to enable return address
signing
- Armv8.3a added instructions to sign the return address to help mitigate
a

[AArch64] - return address signing

- Add a command line options -msign-return-address to enable return address
signing
- Armv8.3a added instructions to sign the return address to help mitigate
against ROP attacks
- This patch adds command line options to generate function attributes that
signal to the back whether return address signing instructions should be
added

Differential revision: https://reviews.llvm.org/D49793

llvm-svn: 340019

show more ...