Move CodeGenOptions from Frontend to Basic

Basic uses CodeGenOptions and should not depend on Frontend.

llvm-svn: 348827

Make CPUDispatch resolver emit dependent functions.

Inline cpu_specific versions referenced before the cpu_dispatch function
weren't properly emitted, since they hadn't been referred to. This
patch

Make CPUDispatch resolver emit dependent functions.

Inline cpu_specific versions referenced before the cpu_dispatch function
weren't properly emitted, since they hadn't been referred to. This
patch ensures that during resolver generation that all appropriate
versions are emitted.

Change-Id: I94c3766aaf9c75ca07a0ad8258efdbb834654ff8
llvm-svn: 348600

show more ...

Remove CodeGen dependencies on Sema.

Move diagnostics from Sema to Frontend (or Common) so that CodeGen no longer
needs to include the Sema diagnostic IDs.

llvm-svn: 348458

Correct 'target' default behavior on redecl, allow forward declaration.

Declarations without the attribute were disallowed because it would be
ambiguous which 'target' it was supposed to be on. For

Correct 'target' default behavior on redecl, allow forward declaration.

Declarations without the attribute were disallowed because it would be
ambiguous which 'target' it was supposed to be on. For example:

void ___attribute__((target("v1"))) foo();
void foo(); // Redecl of above, or fwd decl of below?
void ___attribute__((target("v2"))) foo();

However, a first declaration doesn't have that problem, and erroring
prevents it from working in cases where the forward declaration is
useful.

Additionally, a forward declaration of target==default wouldn't properly
cause multiversioning, so this patch fixes that.

The patch was not split since the 'default' fix would require
implementing the same check for that case, followed by undoing the same
change for the fwd-decl implementation.

Change-Id: I66f2c5bc2477bcd3f7544b9c16c83ece257077b0
llvm-svn: 347805

show more ...

[NFC] Move MultIversioning::Type into Decl so that it can be used in
CodeGen

Change-Id: I32b14edca3501277e0e65672eafe3eea38c6f9ae
llvm-svn: 347791

[codeview] Expose -gcodeview-ghash for global type hashing

Summary:
Experience has shown that the functionality is useful. It makes linking
optimized clang with debug info for me a lot faster, 20s t

[codeview] Expose -gcodeview-ghash for global type hashing

Summary:
Experience has shown that the functionality is useful. It makes linking
optimized clang with debug info for me a lot faster, 20s to 13s. The
type merging phase of PDB writing goes from 10s to 3s.

This removes the LLVM cl::opt and replaces it with a metadata flag.

After this change, users can do the following to use ghash:
- add -gcodeview-ghash to compiler flags
- replace /DEBUG with /DEBUG:GHASH in linker flags

Reviewers: zturner, hans, thakis, takuto.ikuta

Subscribers: aprantl, hiraditya, JDevlieghere, llvm-commits

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

llvm-svn: 347072

show more ...

[NFC] Move storage of dispatch-version to GlobalDecl

As suggested by Richard Smith, and initially put up for review here:
https://reviews.llvm.org/D53341, this patch removes a hack that was used
to

[NFC] Move storage of dispatch-version to GlobalDecl

As suggested by Richard Smith, and initially put up for review here:
https://reviews.llvm.org/D53341, this patch removes a hack that was used
to ensure that proper target-feature lists were used when emitting
cpu-dispatch (and eventually, target-clones) implementations. As a part
of this, the GlobalDecl object is proliferated to a bunch more
locations.

Originally, this was put up for review (see above) to get acceptance on
the approach, though discussion with Richard in San Diego showed he
approved of the approach taken here. Thus, I believe this is acceptable
for Review-After-commit

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

Change-Id: I0a0bd673340d334d93feac789d653e03d9f6b1d5
llvm-svn: 346757

show more ...

Use the correct address space when emitting the ctor function list

This patch modifies clang so that, if compiling for a target that
explicitly specifies a nonzero program memory address space, the

Use the correct address space when emitting the ctor function list

This patch modifies clang so that, if compiling for a target that
explicitly specifies a nonzero program memory address space, the
constructor list global will have the same address space as the
functions it contains.

AVR is the only in-tree backend which has a nonzero program memory
address space.

Without this, the IR verifier would always fail if a constructor
was used on a Harvard architecture backend.

This has no functional change to any in-tree backends except AVR.

llvm-svn: 346520

show more ...

CPU-Dispatch- Fix type of a member function, prevent deferrals

The member type creation for a cpu-dispatch function was not correctly
including the 'this' parameter, so ensure that the type is prope

CPU-Dispatch- Fix type of a member function, prevent deferrals

The member type creation for a cpu-dispatch function was not correctly
including the 'this' parameter, so ensure that the type is properly
determined. Also, disable defer in the cases of emitting the functoins,
as it can end up resulting in the wrong version being emitted.

Change-Id: I0b8fc5e0b0d1ae1a9d98fd54f35f27f6e5d5d083
llvm-svn: 345838

show more ...

CPU-Dispatch-- Fix conflict between 'generic' and 'pentium'

When a dispatch function was being emitted that had both a generic and a
pentium configuration listed, we would assert. This is because n

CPU-Dispatch-- Fix conflict between 'generic' and 'pentium'

When a dispatch function was being emitted that had both a generic and a
pentium configuration listed, we would assert. This is because neither
configuration has any 'features' associated with it so they were both
considered the 'default' version. 'pentium' lacks any features because
we implement it in terms of __builtin_cpu_supports (instead of Intel
proprietary checks), which is unable to decern between the two.

The fix for this is to omit the 'generic' version from the dispatcher if
both are present. This permits existing code to compile, and still will
choose the 'best' version available (since 'pentium' is technically
better than 'generic').

Change-Id: I4b69f3e0344e74cbdbb04497845d5895dd05fda0
llvm-svn: 345826

show more ...

NFC: Remove the ObjC1/ObjC2 distinction from clang (and related projects)

We haven't supported compiling ObjC1 for a long time (and never will again), so
there isn't any reason to keep these separat

NFC: Remove the ObjC1/ObjC2 distinction from clang (and related projects)

We haven't supported compiling ObjC1 for a long time (and never will again), so
there isn't any reason to keep these separate. This patch replaces
LangOpts::ObjC1 and LangOpts::ObjC2 with LangOpts::ObjC.

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

llvm-svn: 345637

show more ...

PR31978: Don't crash if CodeGen sees a top-level BindingDecl.

llvm-svn: 345362

CodeGen: correct the case for swift 4.2, 5.0

This corrects the leader for the swift names. The encoding for 4.2 and
5.0 differ by a single bit on the second character and were swapped.

llvm-svn: 3

CodeGen: correct the case for swift 4.2, 5.0

This corrects the leader for the swift names. The encoding for 4.2 and
5.0 differ by a single bit on the second character and were swapped.

llvm-svn: 345360

show more ...

Change keep-static-consts to work on static storage duration, not
storage class.

To be more in line with what GCC does, switch the condition to be based
on the Static Storage duration instead of the

Change keep-static-consts to work on static storage duration, not
storage class.

To be more in line with what GCC does, switch the condition to be based
on the Static Storage duration instead of the storage class.

Change-Id: I8e959d762433cda48855099353bf3c950b9d54b8
llvm-svn: 345302

show more ...

Implement Function Multiversioning for Non-ELF Systems.

Similar to how ICC handles CPU-Dispatch on Windows, this patch uses the
resolver function directly to forward the call to the proper function.

Implement Function Multiversioning for Non-ELF Systems.

Similar to how ICC handles CPU-Dispatch on Windows, this patch uses the
resolver function directly to forward the call to the proper function.
This is not nearly as efficient as IFuncs of course, but is still quite
useful for large functions specifically developed for certain
processors.

This is unfortunately still limited to x86, since it depends on
__builtin_cpu_supports and __builtin_cpu_is, which are x86 builtins.

The naming for the resolver/forwarding function for cpu-dispatch was
taken from ICC's implementation, which uses the unmodified name for this
(no mangling additions). This is possible, since cpu-dispatch uses '.A'
for the 'default' version.

In 'target' multiversioning, this function keeps the '.resolver'
extension in order to keep the default function keeping the default
mangling.

Change-Id: I4731555a39be26c7ad59a2d8fda6fa1a50f73284

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

llvm-svn: 345298

show more ...

CodeGen: alter CFConstantString class name for swift 5.0

Swift 5.0 has changed the name decoration for swift symbols, using a 'S' sigil
rather than 's' as in 4.2. Adopt the new convention.

llvm-sv

CodeGen: alter CFConstantString class name for swift 5.0

Swift 5.0 has changed the name decoration for swift symbols, using a 'S' sigil
rather than 's' as in 4.2. Adopt the new convention.

llvm-svn: 345291

show more ...

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 ...

CodeGen: extract some local variables in CFConstantString creation (NFC)

Extract the reference to the ASTContext and Triple and use them throughout the
function. This is simply a cosmetic cleanup w

CodeGen: extract some local variables in CFConstantString creation (NFC)

Extract the reference to the ASTContext and Triple and use them throughout the
function. This is simply a cosmetic cleanup while in the area. NFC.

llvm-svn: 345160

show more ...

[CodeGen] Attach InlineHint to more functions

For instantiated functions, search the template pattern to see if it marked
inline to determine if InlineHint attribute should be added to the function.

[CodeGen] Attach InlineHint to more functions

For instantiated functions, search the template pattern to see if it marked
inline to determine if InlineHint attribute should be added to the function.

llvm-svn: 344987

show more ...

Give Multiversion-inline functions linkonce linkage

Since multiversion variant functions can be inline, in C they become
available-externally linkage. This ends up causing the variants to not
be em

Give Multiversion-inline functions linkonce linkage

Since multiversion variant functions can be inline, in C they become
available-externally linkage. This ends up causing the variants to not
be emitted, and not available to the linker.

The solution is to make sure that multiversion functions are always
emitted by marking them linkonce.

Change-Id: I897aa37c7cbba0c1eb2c57ee881d5000a2113b75
llvm-svn: 344957

show more ...

NFC: Remove trailing space from CodeGenModule.cpp

llvm-svn: 344668

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 ...

clang: Allow ifunc resolvers to accept arguments

When ifunc support was added to Clang (r265917) it did not allow
resolvers to take function arguments. This was based on GCC's
documentation, which

clang: Allow ifunc resolvers to accept arguments

When ifunc support was added to Clang (r265917) it did not allow
resolvers to take function arguments. This was based on GCC's
documentation, which states resolvers return a pointer and take no
arguments.

However, GCC actually allows resolvers to take arguments, and glibc (on
non-x86 platforms) and FreeBSD (on x86 and arm64) pass some CPU
identification information as arguments to ifunc resolvers. I believe
GCC's documentation is simply incorrect / out-of-date.

FreeBSD already removed the prohibition in their in-tree Clang copy.

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

llvm-svn: 344100

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 ...

llvm::sort(C.begin(), C.end(), ...) -> llvm::sort(C, ...)

Summary: The convenience wrapper in STLExtras is available since rL342102.

Reviewers: rsmith, #clang, dblaikie

Reviewed By: rsmith, #clang

llvm::sort(C.begin(), C.end(), ...) -> llvm::sort(C, ...)

Summary: The convenience wrapper in STLExtras is available since rL342102.

Reviewers: rsmith, #clang, dblaikie

Reviewed By: rsmith, #clang

Subscribers: mgrang, arphaman, kadircet, cfe-commits

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

llvm-svn: 343147

show more ...