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

Revert "Revert r347417 "Re-Reinstate 347294 with a fix for the failures.""

It seems the two failing tests can be simply fixed after r348037

Fix 3 cases in Analysis/builtin-functions.cpp
Delete the

Revert "Revert r347417 "Re-Reinstate 347294 with a fix for the failures.""

It seems the two failing tests can be simply fixed after r348037

Fix 3 cases in Analysis/builtin-functions.cpp
Delete the bad CodeGen/builtin-constant-p.c for now

llvm-svn: 348053

show more ...

Revert r347417 "Re-Reinstate 347294 with a fix for the failures."

Kept the "indirect_builtin_constant_p" test case in test/SemaCXX/constant-expression-cxx1y.cpp
while we are investigating why the fo

Revert r347417 "Re-Reinstate 347294 with a fix for the failures."

Kept the "indirect_builtin_constant_p" test case in test/SemaCXX/constant-expression-cxx1y.cpp
while we are investigating why the following snippet fails:

extern char extern_var;
struct { int a; } a = {__builtin_constant_p(extern_var)};

llvm-svn: 348039

show more ...

Re-commit r347417 "Re-Reinstate 347294 with a fix for the failures."

This was reverted in r347656 due to me thinking it caused a miscompile of
Chromium. Turns out it was the Chromium code that was b

Re-commit r347417 "Re-Reinstate 347294 with a fix for the failures."

This was reverted in r347656 due to me thinking it caused a miscompile of
Chromium. Turns out it was the Chromium code that was broken.

llvm-svn: 347756

show more ...

Revert r347417 "Re-Reinstate 347294 with a fix for the failures."

This caused a miscompile in Chrome (see crbug.com/908372) that's
illustrated by this small reduction:

static bool f(int *a, int *

Revert r347417 "Re-Reinstate 347294 with a fix for the failures."

This caused a miscompile in Chrome (see crbug.com/908372) that's
illustrated by this small reduction:

static bool f(int *a, int *b) {
return !__builtin_constant_p(b - a) || (!(b - a));
}

int arr[] = {1,2,3};

bool g() {
return f(arr, arr + 3);
}

$ clang -O2 -S -emit-llvm a.cc -o -

g() should return true, but after r347417 it became false for some reason.

This also reverts the follow-up commits.

r347417:
> Re-Reinstate 347294 with a fix for the failures.
>
> Don't try to emit a scalar expression for a non-scalar argument to
> __builtin_constant_p().
>
> Third time's a charm!

r347446:
> The result of is.constant() is unsigned.

r347480:
> A __builtin_constant_p() returns 0 with a function type.

r347512:
> isEvaluatable() implies a constant context.
>
> Assume that we're in a constant context if we're asking if the expression can
> be compiled into a constant initializer. This fixes the issue where a
> __builtin_constant_p() in a compound literal was diagnosed as not being
> constant, even though it's always possible to convert the builtin into a
> constant.

r347531:
> A "constexpr" is evaluated in a constant context. Make sure this is reflected
> if a __builtin_constant_p() is a part of a constexpr.

llvm-svn: 347656

show more ...

Re-Reinstate 347294 with a fix for the failures.

Don't try to emit a scalar expression for a non-scalar argument to
__builtin_constant_p().

Third time's a charm!

llvm-svn: 347417

Revert r347364 again, the fix was incomplete.

llvm-svn: 347389

Reinstate 347294 with a fix for the failures.

EvaluateAsInt() is sometimes called in a constant context. When that's the
case, we need to specify it as so.

llvm-svn: 347364

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

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] Always emit the 'min-legal-vector-width' attribute even when the value is 0.

The X86 backend will need to see the attribute to make decisions. If it isn't present the backend will have to

[CodeGen] Always emit the 'min-legal-vector-width' attribute even when the value is 0.

The X86 backend will need to see the attribute to make decisions. If it isn't present the backend will have to assume large vectors may be present.

llvm-svn: 345237

show more ...

[CodeGen] Update min-legal-vector width based on function argument and return types

This is a continuation of my patches to inform the X86 backend about what the largest IR types are in the function

[CodeGen] Update min-legal-vector width based on function argument and return types

This is a continuation of my patches to inform the X86 backend about what the largest IR types are in the function so that we can restrict the backend type legalizer to prevent 512-bit vectors on SKX when -mprefer-vector-width=256 is specified if no explicit 512 bit vectors were specified by the user.

This patch updates the vector width based on the argument and return types of the current function and from the types of any functions it calls. This is intended to make sure the backend type legalizer doesn't disturb any types that are required for ABI.

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

llvm-svn: 345168

show more ...

Use llvm::{all,any,none}_of instead std::{all,any,none}_of. NFC

llvm-svn: 344859

[CodeGen] Revert commit https://reviews.llvm.org/rL342717

llvm-svn: 342912

[CodeGen] Add to emitted DebugLoc information about coverage when it's required

Summary:
Some lines have a hit counter where they should not have one.
Cleanup stuff is located to the last line of th

[CodeGen] Add to emitted DebugLoc information about coverage when it's required

Summary:
Some lines have a hit counter where they should not have one.
Cleanup stuff is located to the last line of the body which is most of the time a '}'.
And Exception stuff is added at the beginning of a function and at the end (represented by '{' and '}').
So in such cases, the DebugLoc used in GCOVProfiling.cpp must be marked as not covered.
This patch is a followup of https://reviews.llvm.org/D49915.
Tests in projects/compiler_rt are fixed by: https://reviews.llvm.org/D49917

Reviewers: marco-c, davidxl

Reviewed By: marco-c

Subscribers: dblaikie, cfe-commits, sylvestre.ledru

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

llvm-svn: 342717

show more ...

[XRay][clang] Emit "never-instrument" attribute

Summary:
Before this change, we only emit the XRay attributes in LLVM IR when the
-fxray-instrument flag is provided. This may cause issues with thinl

[XRay][clang] Emit "never-instrument" attribute

Summary:
Before this change, we only emit the XRay attributes in LLVM IR when the
-fxray-instrument flag is provided. This may cause issues with thinlto
when the final binary is being built/linked with -fxray-instrument, and
the constitutent LLVM IR gets re-lowered with xray instrumentation.

With this change, we can honour the "never-instrument "attributes
provided in the source code and preserve those in the IR. This way, even
in thinlto builds, we retain the attributes which say whether functions
should never be XRay instrumented.

This change addresses llvm.org/PR38922.

Reviewers: mboerger, eizan

Subscribers: mehdi_amini, dexonsmith, cfe-commits, llvm-commits

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

llvm-svn: 342200

show more ...

[NFC]Refactor MultiVersion Resolver Emission to combine types

Previously, both types (plus the future target-clones) of
multiversioning had a separate ResolverOption structure and emission
function.

[NFC]Refactor MultiVersion Resolver Emission to combine types

Previously, both types (plus the future target-clones) of
multiversioning had a separate ResolverOption structure and emission
function. This patch combines the two, at the expense of a slightly
more expensive sorting function.

llvm-svn: 342152

show more ...

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

[CodeGen] Implicitly set stackrealign on the main function, if custom stack alignment is used

If using a custom stack alignment, one is expected to make sure
that all callers provide such alignment,

[CodeGen] Implicitly set stackrealign on the main function, if custom stack alignment is used

If using a custom stack alignment, one is expected to make sure
that all callers provide such alignment, or realign the stack in
all entry points (and callbacks).

Despite this, the compiler can assume that the main function will
need realignment in these cases, since the startup routines calling
the main function most probably won't provide the custom alignment.

This matches what GCC does in similar cases; if compiling with
-mincoming-stack-boundary=X -mpreferred-stack-boundary=X, GCC normally
assumes such alignment on entry to a function, but specifically for
the main function still does realignment.

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

llvm-svn: 340334

show more ...

[CodeGen] Merge equivalent block copy/helper functions.

Clang generates copy and dispose helper functions for each block literal
on the stack. Often these functions are equivalent for different bloc

[CodeGen] Merge equivalent block copy/helper functions.

Clang generates copy and dispose helper functions for each block literal
on the stack. Often these functions are equivalent for different blocks.
This commit makes changes to merge equivalent copy and dispose helper
functions and reduce code size.

To enable merging equivalent copy/dispose functions, the captured object
infomation is encoded into the helper function name. This allows IRGen
to check whether an equivalent helper function has already been emitted
and reuse the function instead of generating a new helper function
whenever a block is defined. In addition, the helper functions are
marked as linkonce_odr to enable merging helper functions that have the
same name across translation units and marked as unnamed_addr to enable
the linker's deduplication pass to merge functions that have different
names but the same content.

rdar://problem/42640608

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

llvm-svn: 339438

show more ...

Port getLocStart -> getBeginLoc

Reviewers: teemperor!

Subscribers: jholewinski, whisperity, jfb, cfe-commits

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

llvm-svn: 339385

Implement cpu_dispatch/cpu_specific Multiversioning

As documented here: https://software.intel.com/en-us/node/682969 and
https://software.intel.com/en-us/node/523346. cpu_dispatch multiversioning
is

Implement cpu_dispatch/cpu_specific Multiversioning

As documented here: https://software.intel.com/en-us/node/682969 and
https://software.intel.com/en-us/node/523346. cpu_dispatch multiversioning
is an ICC feature that provides for function multiversioning.

This feature is implemented with two attributes: First, cpu_specific,
which specifies the individual function versions. Second, cpu_dispatch,
which specifies the location of the resolver function and the list of
resolvable functions.

This is valuable since it provides a mechanism where the resolver's TU
can be specified in one location, and the individual implementions
each in their own translation units.

The goal of this patch is to be source-compatible with ICC, so this
implementation diverges from the ICC implementation in a few ways:
1- Linux x86/64 only: This implementation uses ifuncs in order to
properly dispatch functions. This is is a valuable performance benefit
over the ICC implementation. A future patch will be provided to enable
this feature on Windows, but it will obviously more closely fit ICC's
implementation.
2- CPU Identification functions: ICC uses a set of custom functions to identify
the feature list of the host processor. This patch uses the cpu_supports
functionality in order to better align with 'target' multiversioning.
1- cpu_dispatch function def/decl: ICC's cpu_dispatch requires that the function
marked cpu_dispatch be an empty definition. This patch supports that as well,
however declarations are also permitted, since the linker will solve the
issue of multiple emissions.

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

llvm-svn: 337552

show more ...

[NFC] Switch CodeGenFunction to use value init instead of member init lists

The member init list for the sole constructor for CodeGenFunction
has gotten out of hand, so this patch moves the non-para

[NFC] Switch CodeGenFunction to use value init instead of member init lists

The member init list for the sole constructor for CodeGenFunction
has gotten out of hand, so this patch moves the non-parameter-dependent
initializations into the member value inits.

Note: This is what was intended to be committed in r336726
llvm-svn: 336729

show more ...

Revert -r336726, which included more files than intended.

llvm-svn: 336727

[NFC] Switch CodeGenFunction to use value init instead of member init lists

The member init list for the sole constructor for CodeGenFunction
has gotten out of hand, so this patch moves the non-para

[NFC] Switch CodeGenFunction to use value init instead of member init lists

The member init list for the sole constructor for CodeGenFunction
has gotten out of hand, so this patch moves the non-parameter-dependent
initializations into the member value inits.

llvm-svn: 336726

show more ...