Treat `std::move`, `forward`, and `move_if_noexcept` as builtins.

We still require these functions to be declared before they can be used,
but don't instantiate their definitions unless their addres

Treat `std::move`, `forward`, and `move_if_noexcept` as builtins.

We still require these functions to be declared before they can be used,
but don't instantiate their definitions unless their addresses are
taken. Instead, code generation, constant evaluation, and static
analysis are given direct knowledge of their effect.

This change aims to reduce various costs associated with these functions
-- per-instantiation memory costs, compile time and memory costs due to
creating out-of-line copies and inlining them, code size at -O0, and so
on -- so that they are not substantially more expensive than a cast.
Most of these improvements are very small, but I measured a 3% decrease
in -O0 object file size for a simple C++ source file using the standard
library after this change.

We now automatically infer the `const` and `nothrow` attributes on these
now-builtin functions, in particular meaning that we get a warning for
an unused call to one of these functions.

In C++20 onwards, we disallow taking the addresses of these functions,
per the C++20 "addressable function" rule. In earlier language modes, a
compatibility warning is produced but the address can still be taken.

The same infrastructure is extended to the existing MSVC builtin
`__GetExceptionInfo`, which is now only recognized in namespace `std`
like it always should have been.

Reviewed By: aaron.ballman

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

show more ...

[OpenCL] Add support of language builtins for OpenCL C 3.0

OpenCL C 3.0 introduces optionality to some builtins, in particularly
to those which are conditionally supported with pipe, device enqueue

[OpenCL] Add support of language builtins for OpenCL C 3.0

OpenCL C 3.0 introduces optionality to some builtins, in particularly
to those which are conditionally supported with pipe, device enqueue
and generic address space features.

The idea is to conditionally support such builtins depending on the language options
being set for a certain feature. This allows users to define functions with names
of those optional builtins in OpenCL (as such names are not reserved).

Reviewed By: Anastasia

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

show more ...

[OpenCL] Defines helper function for kernel language compatible OpenCL version

This change defines a helper function getOpenCLCompatibleVersion()
inside LangOptions class. The function contains mapp

[OpenCL] Defines helper function for kernel language compatible OpenCL version

This change defines a helper function getOpenCLCompatibleVersion()
inside LangOptions class. The function contains mapping between
C++ for OpenCL versions and their corresponding compatible OpenCL
versions. This mapping function should be updated each time a new
C++ for OpenCL language version is introduced. The helper function
is expected to simplify conditions on OpenCL C and C++ for OpenCL
versions inside compiler code.

Code refactoring performed.

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

show more ...

The compiler is crashing when compiling a coroutine intrinsic without
the use of the option fcoroutines-ts. This is a patch to fix this.

Fix for https://bugs.llvm.org/show_bug.cgi?id=50406

[AArch64] ACLE: Fix issue for mismatching enum types with builtins.

This patch fixes an issue with the SVE prefetch and qinc/qdec intrinsics
that take an `enum` argument, but where the builtin proto

[AArch64] ACLE: Fix issue for mismatching enum types with builtins.

This patch fixes an issue with the SVE prefetch and qinc/qdec intrinsics
that take an `enum` argument, but where the builtin prototype encodes
these as `int`. Some code in SemaDecl found the mismatch and chose
to forget about the builtin altogether, which meant that any future
code using that builtin would fail. The code that forgets about the
builtin was actually obsolete after D77491 and should have been removed.
This patch now removes that code.

This patch also fixes another issue with the SVE prefetch intrinsic
when built with C++, where the builtin didn't accept the correct
pointer type, which should be `const void *`.

Reviewed By: tambre

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

show more ...

[CUDA][HIP] add __builtin_get_device_side_mangled_name

Add builtin function __builtin_get_device_side_mangled_name
to get device side manged name for functions and global
variables, which can be use

[CUDA][HIP] add __builtin_get_device_side_mangled_name

Add builtin function __builtin_get_device_side_mangled_name
to get device side manged name for functions and global
variables, which can be used to get symbol address of kernels
or variables by mangled name in dynamically loaded
bundled code objects at run time.

Reviewed by: Artem Belevich

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

show more ...

isBuiltinFunc() uses StringRef instead of const char*

Summary: This prevents a bug when passing nullptr, StringRef ctor would call strlen(nullptr).

Reviewers: vlad.tsyrklevich

Subscribers: cfe-com

isBuiltinFunc() uses StringRef instead of const char*

Summary: This prevents a bug when passing nullptr, StringRef ctor would call strlen(nullptr).

Reviewers: vlad.tsyrklevich

Subscribers: cfe-commits

Tags: #clang

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

show more ...

[OpenCL] Support pipe keyword in C++ mode

Support the OpenCL C pipe feature in C++ for OpenCL mode, to preserve
backwards compatibility with OpenCL C.

Various changes had to be made in Parse and Se

[OpenCL] Support pipe keyword in C++ mode

Support the OpenCL C pipe feature in C++ for OpenCL mode, to preserve
backwards compatibility with OpenCL C.

Various changes had to be made in Parse and Sema to enable
pipe-specific diagnostics, so enable a SemaOpenCL test for C++.

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

llvm-svn: 361382

show more ...

[Builtins] Implement __builtin_is_constant_evaluated for use in C++2a

Summary:
This patch implements `__builtin_is_constant_evaluated` as specifier by [P0595R2](https://wg21.link/p0595r2). It is bui

[Builtins] Implement __builtin_is_constant_evaluated for use in C++2a

Summary:
This patch implements `__builtin_is_constant_evaluated` as specifier by [P0595R2](https://wg21.link/p0595r2). It is built on the back of Bill Wendling's work for `__builtin_constant_p()`.

More tests to come, but early feedback is appreciated.

I plan to implement warnings for common mis-usages like those belowe in a following patch:
```
void foo(int x) {
if constexpr (std::is_constant_evaluated())) { // condition is always `true`. Should use plain `if` instead.
foo_constexpr(x);
} else {
foo_runtime(x);
}
}
```



Reviewers: rsmith, MaskRay, bruno, void

Reviewed By: rsmith

Subscribers: dexonsmith, zoecarver, fdeazeve, kristina, cfe-commits

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

llvm-svn: 359067

show more ...

Revert "Add a new attribute, fortify_stdlib"

This reverts commit r353765. After talking with our c stdlib folks, we decided
to use the existing pass_object_size attribute to implement _FORTIFY_SOURC

Revert "Add a new attribute, fortify_stdlib"

This reverts commit r353765. After talking with our c stdlib folks, we decided
to use the existing pass_object_size attribute to implement _FORTIFY_SOURCE
wrappers, like Bionic does (I didn't realize that pass_object_size could be used
for this purpose). Sorry for the flip/flop, and thanks to James Y. Knight for
pointing this out to me.

llvm-svn: 356103

show more ...

Add a new attribute, fortify_stdlib

This attribute applies to declarations of C stdlib functions
(sprintf, memcpy...) that have known fortified variants
(__sprintf_chk, __memcpy_chk, ...). When appl

Add a new attribute, fortify_stdlib

This attribute applies to declarations of C stdlib functions
(sprintf, memcpy...) that have known fortified variants
(__sprintf_chk, __memcpy_chk, ...). When applied, clang will emit
calls to the fortified variant functions instead of calls to the
defaults.

In GCC, this is done by adding gnu_inline-style wrapper functions,
but that doesn't work for us for variadic functions because we don't
support __builtin_va_arg_pack (and have no intention to).

This attribute takes two arguments, the first is 'type' argument
passed through to __builtin_object_size, and the second is a flag
argument that gets passed through to the variadic checking variants.

rdar://47905754

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

llvm-svn: 353765

show more ...

Update the file headers across all of the LLVM projects in the monorepo
to reflect the new license.

We understand that people may be surprised that we're moving the header
entirely to discuss the ne

Update the file headers across all of the LLVM projects in the monorepo
to reflect the new license.

We understand that people may be surprised that we're moving the header
entirely to discuss the new license. We checked this carefully with the
Foundation's lawyer and we believe this is the correct approach.

Essentially, all code in the project is now made available by the LLVM
project under our new license, so you will see that the license headers
include that license only. Some of our contributors have contributed
code under our old license, and accordingly, we have retained a copy of
our old license notice in the top-level files in each project and
repository.

llvm-svn: 351636

show more ...

Emit !callback metadata and introduce the callback attribute

With commit r351627, LLVM gained the ability to apply (existing) IPO
optimizations on indirections through callbacks, or transitive c

Emit !callback metadata and introduce the callback attribute

With commit r351627, LLVM gained the ability to apply (existing) IPO
optimizations on indirections through callbacks, or transitive calls.
The general idea is that we use an abstraction to hide the middle man
and represent the callback call in the context of the initial caller.
It is described in more detail in the commit message of the LLVM patch
r351627, the llvm::AbstractCallSite class description, and the
language reference section on callback-metadata.

This commit enables clang to emit !callback metadata that is
understood by LLVM. It does so in three different cases:
1) For known broker functions declarations that are directly
generated, e.g., __kmpc_fork_call for the OpenMP pragma parallel.
2) For known broker functions that are identified by their name and
source location through the builtin detection, e.g.,
pthread_create from the POSIX thread API.
3) For user annotated functions that carry the "callback(callee, ...)"
attribute. The attribute has to include the name, or index, of
the callback callee and how the passed arguments can be
identified (as many as the callback callee has). See the callback
attribute documentation for detailed information.

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

llvm-svn: 351629

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

[Builtins][Attributes][X86] Tag all X86 builtins with their required vector width. Add a min_vector_width function attribute and tag all x86 instrinsics with it

This is part of an ongoing attempt at

[Builtins][Attributes][X86] Tag all X86 builtins with their required vector width. Add a min_vector_width function attribute and tag all x86 instrinsics with it

This is part of an ongoing attempt at making 512 bit vectors illegal in the X86 backend type legalizer due to CPU frequency penalties associated with wide vectors on Skylake Server CPUs. We want the loop vectorizer to be able to emit IR containing wide vectors as intermediate operations in vectorized code and allow these wide vectors to be legalized to 256 bits by the X86 backend even though we are targetting a CPU that supports 512 bit vectors. This is similar to what happens with an AVX2 CPU, the vectorizer can emit wide vectors and the backend will split them. We want this splitting behavior, but still be able to use new Skylake instructions that work on 256-bit vectors and support things like masking and gather/scatter.

Of course if the user uses explicit vector code in their source code we need to not split those operations. Especially if they have used any of the 512-bit vector intrinsics from immintrin.h. And we need to make it so that merely using the intrinsics produces the expected code in order to be backwards compatible.

To support this goal, this patch adds a new IR function attribute "min-legal-vector-width" that can indicate the need for a minimum vector width to be legal in the backend. We need to ensure this attribute is set to the largest vector width needed by any intrinsics from immintrin.h that the function uses. The inliner will be reponsible for merging this attribute when a function is inlined. We may also need a way to limit inlining in the future as well, but we can discuss that in the future.

To make things more complicated, there are two different ways intrinsics are implemented in immintrin.h. Either as an always_inline function containing calls to builtins(can be target specific or target independent) or vector extension code. Or as a macro wrapper around a taget specific builtin. I believe I've removed all cases where the macro was around a target independent builtin.

To support the always_inline function case this patch adds attribute((min_vector_width(128))) that can be used to tag these functions with their vector width. All x86 intrinsic functions that operate on vectors have been tagged with this attribute.

To support the macro case, all x86 specific builtins have also been tagged with the vector width that they require. Use of any builtin with this property will implicitly increase the min_vector_width of the function that calls it. I've done this as a new property in the attribute string for the builtin rather than basing it on the type string so that we can opt into it on a per builtin basis and avoid any impact to target independent builtins.

There will be future work to support vectors passed as function arguments and supporting inline assembly. And whatever else we can find that isn't covered by this patch.

Special thanks to Chandler who suggested this direction and reviewed a preview version of this patch. And thanks to Eric Christopher who has had many conversations with me about this issue.

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

llvm-svn: 336583

show more ...

Limit types of builtins that can be redeclared.

As reported here: https://bugs.llvm.org/show_bug.cgi?id=37033
Any usage of a builtin function that uses a va_list by reference
will cause an assertion

Limit types of builtins that can be redeclared.

As reported here: https://bugs.llvm.org/show_bug.cgi?id=37033
Any usage of a builtin function that uses a va_list by reference
will cause an assertion when redeclaring it.

After discussion in the review, it was concluded that the correct
way of accomplishing this fix is to make attempts to redeclare certain
builtins an error. Unfortunately, doing this limitation for all builtins
is likely a breaking change, so this commit simply limits it to
types with custom type checking and those that take a reference.

Two tests needed to be updated to make this work.

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

llvm-svn: 330160

show more ...

[OpenMP] Implement omp_is_initial_device() as builtin

This allows to return the static value that we know at compile time.

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

llvm-svn: 316001

[OpenCL] Add half load and store builtins

This enables load/stores of half type, without half being a legal type.

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

llvm-svn: 312742

[OpenCL] Make OpenCL Builtins added according to the right version.

Currently we only have OpenCL 2.0 Builtins i.e. pipes or address space conversions.

They have to be added only in the version 2.0

[OpenCL] Make OpenCL Builtins added according to the right version.

Currently we only have OpenCL 2.0 Builtins i.e. pipes or address space conversions.

They have to be added only in the version 2.0 compilation mode to make the identifiers
available for use in the other versions.

Review: http://reviews.llvm.org/D20249
llvm-svn: 274509

show more ...

Recommit: R258773 [OpenCL] Pipe builtin functions
Fix arc patch fuzz error.
Summary:
Support for the pipe built-in functions for OpenCL 2.0.
The pipe builtin functions may have infinite kinds of elem

Recommit: R258773 [OpenCL] Pipe builtin functions
Fix arc patch fuzz error.
Summary:
Support for the pipe built-in functions for OpenCL 2.0.
The pipe builtin functions may have infinite kinds of element types, one approach
would be to just generate calls that would always use generic types such as void*.
This patch is based on bader's opencl support patch on SPIR-V branch.

Reviewers: Anastasia, pekka.jaaskelainen

Subscribers: keryell, bader, cfe-commits

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

llvm-svn: 258782

show more ...

Revert "[OpenCL] Pipe builtin functions"

This reverts commit r258773, it broke the build bots:
http://bb.pgr.jp/builders/cmake-clang-x86_64-linux/builds/43853

llvm-svn: 258775

[OpenCL] Pipe builtin functions

Summary:
Support for the pipe built-in functions for OpenCL 2.0.
The pipe builtin functions may have infinite kinds of element types, one approach
would be to just ge

[OpenCL] Pipe builtin functions

Summary:
Support for the pipe built-in functions for OpenCL 2.0.
The pipe builtin functions may have infinite kinds of element types, one approach
would be to just generate calls that would always use generic types such as void*.
This patch is based on bader's opencl support patch on SPIR-V branch.

Reviewers: Anastasia, pekka.jaaskelainen

Subscribers: keryell, bader, cfe-commits

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

llvm-svn: 258773

show more ...

[Driver] Add support for -fno-builtin-foo options.

Addresses PR4941 and rdar://6756912.
http://reviews.llvm.org/D15195

llvm-svn: 256937

Make getTargetBuiltins return an ArrayRef instead of having two out parameters of a pointer and length. NFC

llvm-svn: 250681

[CUDA] Allow parsing of host and device code simultaneously.

* adds -aux-triple option to specify target triple
* propagates aux target info to AST context and Preprocessor
* pulls in target spec

[CUDA] Allow parsing of host and device code simultaneously.

* adds -aux-triple option to specify target triple
* propagates aux target info to AST context and Preprocessor
* pulls in target specific preprocessor macros.
* pulls in target-specific builtins from aux target.
* sets appropriate host or device attribute on builtins.

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

llvm-svn: 248299

show more ...