Add enum and typedef argument support to `-fdeclare-opencl-builtins`,
which was the last major missing feature.
Adding the remaining missing builtins is left as future work.
Differential Revision: https://reviews.llvm.org/D96051
Add the builtin functions brought by the
cl_khr_subgroup_extended_types extension to
`-fdeclare-opencl-builtins`.
Differential Revision: https://reviews.llvm.org/D96279
Add the builtin functions brought by the
cl_khr_subgroup_non_uniform_arithmetic extension to
`-fdeclare-opencl-builtins`.
Differential Revision: https://reviews.llvm.org/D95951
This patch adds possibility to define OpenCL C 3.0 feature macros
via command line option or target setting.
Reviewed By: Anastasia
Differential Revision: https://reviews.llvm.org/D95776
Add the builtin functions brought by the cl_khr_subgroup_ballot
extension to `-fdeclare-opencl-builtins`.
Also add placeholder comments for the other Extended Subgroup
Functions from the OpenCL Extension Specification.
Add a comment clarifying the scope of the test.
Differential Revision: https://reviews.llvm.org/D95523
Until now, the `-fdeclare-opencl-builtins` option behaved differently
compared to inclusion of `opencl-c.h`: builtins that are part of an
extension were only available if the extension was enabled using the
corresponding pragma.
Builtins that belong to an extension are guarded using a preprocessor
macro (that is named after the extension) in `opencl-c.h`. Align the
behaviour of `-fdeclare-opencl-builtins` with this.
Co-authored-by: Anastasia Stulova
Differential Revision: https://reviews.llvm.org/D95616
In Clang today, we parse the different attribute syntaxes
(__attribute__, __declspec, and [[]]) in a fairly rigid order. This
leads to confusion for users when they guess the order incorrectly,
and leads to bug reports like PR24559 or necessitates changes like
D94788.
This patch adds a helper function to allow us to more easily parse
attributes in arbitrary order, and then updates all of the places
where we would parse two or more different syntaxes in a rigid order to
use the helper method. The patch does not attempt to handle Microsoft
attributes ([]) because those are ambiguous with other code constructs
and we don't have any attributes that use the syntax.
Extend testing of increment/decrement operators and make sure these
operators are tested in only one dedicated test file.
Rename logical-ops.cl to operators.cl, as it was already containing
more than just logical operators.
Add testing for the remainder operator on floating point types.
With the internal clang extension '__cl_clang_variadic_functions'
variadic functions are accepted by the frontend.
This is not a fully supported vendor/Khronos extension
as it can only be used on targets with variadic prototype
support or in metaprogramming to represent functions with
generic prototype without calling such functions in the
kernel code.
Tags: #clang
Differential Revision: https://reviews.llvm.org/D94027
The new clang internal extension '__cl_clang_function_pointers'
allows use of function pointers and other features that have
the same functionality:
- Use of member function pointers;
- Unrestricted use of references to functions;
- Virtual member functions.
This not a vendor extension and therefore it doesn't require any
special target support. Exposing this functionality fully
will require vendor or Khronos extension.
Tags: #clang
Differential Revision: https://reviews.llvm.org/D94021
Change "negative" into "invalid" and put "invalid" at the beginning of
the file name, following the bulk of the invalid tests in the
SemaOpenCL directory.
Use the "invalid-" prefix only for tests that contain only invalid
constructs.
Drop the "valid" suffix for CodeGen tests, as inputs in this directory
are supposed to be valid anyway.
The argument to the `vec_step` builtin is not evaluated. Hoist the
diagnostic for this in `Sema::CheckUnaryExprOrTypeTraitOperand` such
that it comes before `Sema::CheckVecStepTraitOperandType`.
A minor side-effect of this change is that it also produces the
warning for `co_await` and `co_yield` as `sizeof` arguments now, which
seems to be reasonable given that the warning is emitted for `typeid`
already.
Differential Revision: https://reviews.llvm.org/D91348
Extended subgroups are library style extensions and therefore
they require no changes in the frontend. This commit:
1. Moves extension macro definitions to the internal headers.
2. Removes extension pragmas because they are not needed.
Tags: #clang
Differential Revision: https://reviews.llvm.org/D92231
The restriction on pointer-to-pointer kernel arguments has been
relaxed in OpenCL 2.0. Apply the same address space restrictions for
pointer argument types to the inner pointer types.
Differential Revision: https://reviews.llvm.org/D92091
opencl-c.h disables all extensions at its end, but opencl-c-base.h
does not, and that causes any inclusion of only opencl-c-base.h to
leave some extensions (such as cl_khr_fp16) enabled. This affects the
-fdeclare-opencl-builtins option for example.
This violates the OpenCL Extension Specification which specifies that
"The initial state of the compiler is as if the directive #pragma
OPENCL EXTENSION all : disable was issued".
Fix by disabling all extensions at the end of opencl-c-base.h and
enable extensions inside opencl.h which relied on opencl-c-base.h
enabling the cl_khr_fp16/64 extensions.
Differential Revision: https://reviews.llvm.org/D91429
Many non-language extensions are defined but also unused. This patch
removes them with their tests as they do not require compiler support.
The cl_khr_select_fprounding_mode extension is also removed because it
has been deprecated since OpenCL 1.1 and Clang doesn't have any specific
support for it.
The cl_khr_context_abort extension is only referred to in "The OpenCL
Specification", version 1.2 and 2.0, in Table 4.3, but no specification
is provided in "The OpenCL Extension Specification" for these versions.
Because it is both unused in Clang and lacks specification, this
extension is removed.
The following extensions are platform extensions that bring new OpenCL
APIs but do not impact the kernel language nor require compiler support.
They are therefore removed.
- cl_khr_gl_sharing, introduced in OpenCL 1.0
- cl_khr_icd, introduced in OpenCL 1.2
- cl_khr_gl_event, introduced in OpenCL 1.1
Note: this extension adds a new API to create cl_event but it also
specifies that these can only be used by clEnqueueAcquireGLObjects.
Hence, they cannot be used on the device side and the extension does
not impact the kernel language.
- cl_khr_d3d10_sharing, introduced in OpenCL 1.1
- cl_khr_d3d11_sharing, introduced in OpenCL 1.2
- cl_khr_dx9_media_sharing, introduced in OpenCL 1.2
- cl_khr_image2d_from_buffer, introduced in OpenCL 1.2
- cl_khr_initialize_memory, introduced in OpenCL 1.2
- cl_khr_gl_depth_images, introduced in OpenCL 1.2
Note: this extension is related to cl_khr_depth_images but only the
latter adds new features to the kernel language.
- cl_khr_spir, introduced in OpenCL 1.2
- cl_khr_egl_event, introduced in OpenCL 1.2
Note: this extension adds a new API to create cl_event but it also
specifies that these can only be used by clEnqueueAcquire* API
functions. Hence, they cannot be used on the device side and the
extension does not impact the kernel language.
- cl_khr_egl_image, introduced in OpenCL 1.2
- cl_khr_terminate_context, introduced in OpenCL 1.2
The minimum required OpenCL version used in OpenCLExtensions.def for
these extensions is not always correct. Removing these address that
issue.
Reviewed By: Anastasia
Differential Revision: https://reviews.llvm.org/D89372
Permitting non-standards-driven "do the best you can" constant-folding
of array bounds is permitted solely as a GNU compatibility feature. We
should not be doing it in any language mode that is attempting to be
conforming.
From https://reviews.llvm.org/D20090 it appears the intent here was to
permit `__constant int` globals to be used in array bounds, but the
change in that patch only added half of the functionality necessary to
support that in the constant evaluator. This patch adds the other half
of the functionality and turns off constant folding for array bounds in
OpenCL.
I couldn't find any spec justification for accepting the kinds of cases
that D20090 accepts, so a reference to where in the OpenCL specification
this is permitted would be useful.
Note that this change also affects the code generation in one test:
because after 'const int n = 0' we now treat 'n' as a constant
expression with value 0, it's now a null pointer, so '(local int *)n'
forms a null pointer rather than a zero pointer.
Reviewed By: Anastasia
Differential Revision: https://reviews.llvm.org/D89520
This patch introduces 2 new address spaces in OpenCL: global_device and global_host
which are a subset of a global address space, so the address space scheme will be
looking like:
```
generic->global->host
->device
->private
->local
constant
```
Justification: USM allocations may be associated with both host and device memory. We
want to give users a way to tell the compiler the allocation type of a USM pointer for
optimization purposes. (Link to the Unified Shared Memory extension:
https://github.com/intel/llvm/blob/sycl/sycl/doc/extensions/USM/cl_intel_unified_shared_memory.asciidoc)
Before this patch USM pointer could be only in opencl_global
address space, hence a device backend can't tell if a particular pointer
points to host or device memory. On FPGAs at least we can generate more
efficient hardware code if the user tells us where the pointer can point -
being able to distinguish between these types of pointers at compile time
allows us to instantiate simpler load-store units to perform memory
transactions.
Patch by Dmitry Sidorov.
Reviewed By: Anastasia
Differential Revision: https://reviews.llvm.org/D82174
OpenCL 2.0 does not allow block arguments, primarily because it is
difficult to support function pointers on the various architectures
that OpenCL targets. Clang was still accepting them.
Rename and reuse the `err_opencl_half_param` diagnostic.
Fixes PR46324.
Differential Revision: https://reviews.llvm.org/D82313
This reverts commit defd43a5b393bb63a902042adf578081b03b171d.
with correction to solve msan report
To solve https://bugs.llvm.org/show_bug.cgi?id=46166 where the
floating point settings in PCH files aren't compatible, rewrite
FPFeatures to use a delta in the settings rather than absolute settings.
With this patch, these floating point options can be benign.
Reviewers: rjmccall
Differential Revision: https://reviews.llvm.org/D81869
This reverts commit b55d723ed61052b77e720dcffecac43abe873186.
Reapply Modify FPFeatures to use delta not absolute settings
To solve https://bugs.llvm.org/show_bug.cgi?id=46166 where the
floating point settings in PCH files aren't compatible, rewrite
FPFeatures to use a delta in the settings rather than absolute settings.
With this patch, these floating point options can be benign.
Reviewers: rjmccall
Differential Revision: https://reviews.llvm.org/D81869
This reverts commit 3a748cbf86cea3844fada04eeff4cc64b01f67e0.
I'm reverting this commit because I forgot to format the commit message
propertly. Sorry for the thrash.
Summary:
__builtin_amdgcn_atomic_inc32(int *Ptr, int Val, unsigned MemoryOrdering, const char *SyncScope)
__builtin_amdgcn_atomic_inc64(int64_t *Ptr, int64_t Val, unsigned MemoryOrdering, const char *SyncScope)
__builtin_amdgcn_atomic_dec32(int *Ptr, int Val, unsigned MemoryOrdering, const char *SyncScope)
__builtin_amdgcn_atomic_dec64(int64_t *Ptr, int64_t Val, unsigned MemoryOrdering, const char *SyncScope)
First and second arguments gets transparently passed to the amdgcn atomic
inc/dec intrinsic. Fifth argument of the intrinsic is set as true if the
first argument of the builtin is a volatile pointer. The third argument of
this builtin is one of the memory-ordering specifiers ATOMIC_ACQUIRE,
ATOMIC_RELEASE, ATOMIC_ACQ_REL, or ATOMIC_SEQ_CST following C++11 memory
model semantics. This is mapped to corresponding LLVM atomic memory ordering
for the atomic inc/dec instruction using CLANG atomic C ABI. The fourth
argument is an AMDGPU-specific synchronization scope defined as string.
Reviewers: arsenm, sameerds, JonChesterfield, jdoerfert
Reviewed By: arsenm, sameerds
Subscribers: kzhuravl, jvesely, wdng, nhaehnle, yaxunl, dstuttard, tpr, t-tye, jfb, kerbowa, cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D80804
Added extensions and their function declarations into
the standard header.
Patch by Piotr Fusik!
Tags: #clang
Differential Revision: https://reviews.llvm.org/D79781
Summary:
This is a small improvement for OpenCL diagnostics, but is also useful
for our CHERI fork, as our __capability qualifier is suppressed from
diagnostics when all pointers are capabilities, only being used when pointers
need to be explicitly opted-in to being capabilities.
Reviewers: rsmith, Anastasia, aaron.ballman
Reviewed By: Anastasia, aaron.ballman
Subscribers: aaron.ballman, arichardson, cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D78777
Expose llvm fence instruction as clang builtin for AMDGPU target
__builtin_amdgcn_fence(unsigned int memoryOrdering, const char *syncScope)
The first argument of this builtin is one of the memory-ordering specifiers
__ATOMIC_ACQUIRE, __ATOMIC_RELEASE, __ATOMIC_ACQ_REL, or __ATOMIC_SEQ_CST
following C++11 memory model semantics. This is mapped to corresponding
LLVM atomic memory ordering for the fence instruction using LLVM atomic C
ABI. The second argument is an AMDGPU-specific synchronization scope
defined as string.
Reviewed By: sameerds
Differential Revision: https://reviews.llvm.org/D75917
Add the sub-group builtin functions from the OpenCL Extension
specification. This patch excludes the sub_group_barrier builtins
that take argument types not yet handled by the
`-fdeclare-opencl-builtins` machinery.
Co-authored-by: Pierre Gondois <pierre.gondois@arm.com>
Compute and propagate conversion kind to diagnostics helper in C++
to provide more specific diagnostics about incorrect implicit
conversions in assignments, initializations, params, etc...
Duplicated some diagnostics as errors because C++ is more strict.
Tags: #clang
Differential Revision: https://reviews.llvm.org/D74116
The `-fdeclare-opencl-builtins` option was accepting saturated
conversions for non-integer types, which contradicts both the OpenCL
specification (v2.0 s6.2.3) and Clang's opencl-c.h file.
Address space conversion changes pointer representation.
This commit disallows such conversions when they are not
legal i.e. for the nested pointers even with compatible
address spaces. Because the address space conversion in
the nested levels can't be generated to modify the pointers
correctly. The behavior implemented is as follows:
- Any implicit conversions of nested pointers with different
address spaces is rejected.
- Any conversion of address spaces in nested pointers in safe
casts (e.g. const_cast or static_cast) is rejected.
- Conversion in low level C-style or reinterpret_cast is accepted
but with a warning (this aligns with OpenCL C behavior).
Fixes PR39674
Differential Revision: https://reviews.llvm.org/D73360
This CL adds clang declarations of built-in functions for AMDGPU MFMA intrinsics and instructions.
OpenCL tests for new built-ins are included.
Differential Revision: https://reviews.llvm.org/D72723
The language wording change forgot to update overload resolution to rank
implicit conversion sequences based on qualification conversions in
reference bindings. The anticipated resolution for that oversight is
implemented here -- we order candidates based on qualification
conversion, not only on top-level cv-qualifiers, including ranking
reference bindings against non-reference bindings if they differ in
non-top-level qualification conversions.
For OpenCL/C++, this allows reference binding between pointers with
differing (nested) address spaces. This makes the behavior of reference
binding consistent with that of implicit pointer conversions, as is the
purpose of this change, but that pre-existing behavior for pointer
conversions is itself probably not correct. In any case, it's now
consistently the same behavior and implemented in only one place.
This reinstates commit de21704ba96fa80d3e9402f12c6505917a3885f4,
reverted in commit d8018233d1ea4234de68d5b4593abd773db79484, with
workarounds for some overload resolution ordering problems introduced by
CWG2352.
This reverts commit de21704ba96fa80d3e9402f12c6505917a3885f4.
Regressed/causes this to error due to ambiguity:
void f(const int * const &);
void f(int *);
int main() {
int * x;
f(x);
}
(in case it's important - the original case where this turned up was a
member function overload in a class template with, essentially:
f(const T1&)
f(T2*)
(where T1 == X const *, T2 == X))
It's not super clear to me if this ^ is expected behavior, in which case
I'm sorry about the revert & happy to look into ways to fix the original
code.
