[CodeGen] Clarify comment about COFF common symbol alignment

After a discussion on the commit thread, it seems the 32 byte alignment
limitation is an MSVC toolchain artifact, not an inherent COFF
re

[CodeGen] Clarify comment about COFF common symbol alignment

After a discussion on the commit thread, it seems the 32 byte alignment
limitation is an MSVC toolchain artifact, not an inherent COFF
restriction. Clarify the comment accordingly, since saying COFF in the
comment but using isKnownWindowsMSVCEnvironment in the conditional is
confusing. Also add a newline before the comment, which is consistent
with the local style.

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

llvm-svn: 350754

show more ...

Limit COFF 'common' emission to <=32 alignment types.

As reported in PR33035, LLVM crashes if given a common object with an
alignment of greater than 32 bits. This is because the COFF file format
do

Limit COFF 'common' emission to <=32 alignment types.

As reported in PR33035, LLVM crashes if given a common object with an
alignment of greater than 32 bits. This is because the COFF file format
does not support these alignments, so emitting them is broken anyway.

This patch changes any global definitions greater than 32 bit alignment
to no longer be in 'common'.

https://bugs.llvm.org/show_bug.cgi?id=33035

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

Change-Id: I48609289753b7f3b58c5e2bc1712756750fbd45a
llvm-svn: 350643

show more ...

CodeGen: fix autolink emission on ELF

The autolinking extension for ELF uses a slightly different format for
encoding the autolink information compared to COFF and MachO. Account
for this in the CG

CodeGen: fix autolink emission on ELF

The autolinking extension for ELF uses a slightly different format for
encoding the autolink information compared to COFF and MachO. Account
for this in the CGM to ensure that we do not assert when emitting
assembly or an object file.

llvm-svn: 350476

show more ...

CodeGen: switch iteration to range based for loop (NFC)

Change a loop to range based instead while working on cleaning up some
modules autolinking issues on Linux. NFC.

llvm-svn: 350472

[CUDA] Treat extern global variable shadows same as regular extern vars.

This fixes compiler crash when we attempted to compile this code:

extern __device__ int data;
__device__ int data = 1;

Diff

[CUDA] Treat extern global variable shadows same as regular extern vars.

This fixes compiler crash when we attempted to compile this code:

extern __device__ int data;
__device__ int data = 1;

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

llvm-svn: 349981

show more ...

Implement -frecord-command-line (-frecord-gcc-switches)

Implement options in clang to enable recording the driver command-line
in an ELF section.

Implement a new special named metadata, llvm.comman

Implement -frecord-command-line (-frecord-gcc-switches)

Implement options in clang to enable recording the driver command-line
in an ELF section.

Implement a new special named metadata, llvm.commandline, to support
frontends embedding their command-line options in IR/ASM/ELF.

This differs from the GCC implementation in some key ways:

* In GCC there is only one command-line possible per compilation-unit,
in LLVM it mirrors llvm.ident and multiple are allowed.
* In GCC individual options are separated by NULL bytes, in LLVM entire
command-lines are separated by NULL bytes. The advantage of the GCC
approach is to clearly delineate options in the face of embedded
spaces. The advantage of the LLVM approach is to support merging
multiple command-lines unambiguously, while handling embedded spaces
with escaping.

Differential Revision: https://reviews.llvm.org/D54487
Clang Differential Revision: https://reviews.llvm.org/D54489

llvm-svn: 349155

show more ...

[CUDA] Make all host-side shadows of device-side variables undef.

The host-side code can't (and should not) access the values that may
only exist on the device side. E.g. address of a __device__ fun

[CUDA] Make all host-side shadows of device-side variables undef.

The host-side code can't (and should not) access the values that may
only exist on the device side. E.g. address of a __device__ function
does not exist on the host side as we don't generate the code for it there.

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

llvm-svn: 349087

show more ...

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