This wasn't setting some of the features from older generations.

llvm-svn: 364123

llvm-svn: 363986

llvm-svn: 363871

........
Depends on rL363678 which was reverted at rL363797

llvm-svn: 363824

llvm-svn: 363684

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

llvm-svn: 363345

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

llvm-svn: 363341

LLVM IR recently added a Type parameter to the byval Attribute, so that
when pointers become opaque and no longer have an element type the
information will still be present in IR.

For now the Type parameter is optional (which is why Clang didn't need
this change at the time), but it will become mandatory soon.

llvm-svn: 362652

Since byval is now a typed attribute it gets sorted slightly differently by
LLVM when the order of attributes is being canonicalized. This updates the few
Clang tests that depend on the old order.

Clang patch is unchanged.

llvm-svn: 362129

C++ is derived from OpenCL v2.0 therefore set the versions
identically.

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

llvm-svn: 362102

Support logical operators on vectors in C++ for OpenCL mode, to
preserve backwards compatibility with OpenCL C.

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

llvm-svn: 362087

The underlying LLVM change couldn't cope with llvm-link and broke LTO builds.

llvm-svn: 362028

Since byval is now a typed attribute it gets sorted slightly differently by
LLVM when the order of attributes is being canonicalized. This updates the few
Clang tests that depend on the old order.

llvm-svn: 362013

OpenCL spec v2.0 s6.13.14:

Samplers can also be declared as global constants in the program
source using the following syntax.

   const sampler_t <sampler name> = <value>
This works fine for OpenCL 1.2 but fails for 2.0, because clang duduces
address space of file-scope const sampler variable to be in global address
space whereas spec v2.0 s6.9.b forbids file-scope sampler variable to be
in global address space.

The fix is not to deduce address space for file-scope sampler variables.

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

llvm-svn: 361757

The specification is available in the Khronos OpenCL registry:

https://www.khronos.org/registry/OpenCL/extensions/arm/cl_arm_integer_dot_product.txt



Signed-off-by: Kevin Petit <kevin.petit@arm.com>
llvm-svn: 361641

llvm-svn: 361004

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

llvm-svn: 360634

The semantics for converting nested pointers between address
spaces are not very well defined. Some conversions which do not
really carry any meaning only produce warnings, and in some cases
warnings hide invalid conversions, such as 'global int*' to
'local float*'!

This patch changes the logic in checkPointerTypesForAssignment
and checkAddressSpaceCast to fail properly on implicit conversions
that should definitely not be permitted. We also dig deeper into the
pointer types and warn on explicit conversions where the address
space in a nested pointer changes, regardless of whether the address
space is compatible with the corresponding pointer nesting level
on the destination type.

Fixes PR39674!

Patch by ebevhan (Bevin Hansson)!

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

llvm-svn: 360258

AMDGPU currently relies on global properties being set before
setTargetProperties is called. Existing targets like MIPS which rely on
setTargetProperties do not rely on the current behavior, so this patch
moves the call later in SetFunctionAttributes.

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

llvm-svn: 359039

[OpenCL] Re-fix invalid address space generation for clk_event_t arguments of enqueue_kernel builtin function

Summary:
https://reviews.llvm.org/D53809 fixed wrong address space(assert in debug build)
generated for event_ret argument. But exactly the same problem exists for
event_wait_list argument. This patch should fix both.

Reviewers: Anastasia, yaxunl

Reviewed By:  Anastasia

Subscribers: kristina, ebevhan, cfe-commits

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

llvm-svn: 358151

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

llvm-svn: 357792

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

llvm-svn: 356947

Summary:
[OpenCL] Generate 'unroll.enable' metadata for  __attribute__((opencl_unroll_hint))
    
For both !{!"llvm.loop.unroll.enable"} and !{!"llvm.loop.unroll.full"} the unroller
will try to fully unroll a loop unless the trip count is not known at compile time.
In that case for '.full' metadata no unrolling will be processed, while for '.enable'
the loop will be partially unrolled with a heuristically chosen unroll factor.
    
See: docs/LanguageExtensions.rst
    
From https://www.khronos.org/registry/OpenCL/sdk/2.0/docs/man/xhtml/attributes-loopUnroll.html

    __attribute__((opencl_unroll_hint))
    for (int i=0; i<2; i++)
    {
        ...
    }
    
In the example above, the compiler will determine how much to unroll the loop.

    
Before the patch for  __attribute__((opencl_unroll_hint)) was generated metadata
!{!"llvm.loop.unroll.full"}, which limits ability of loop unroller to decide, how
much to unroll the loop.

Reviewers: Anastasia, yaxunl

Reviewed By: Anastasia

Subscribers: zzheng, dmgreen, jdoerfert, cfe-commits, asavonic, AlexeySotkin

Tags: #clang

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

llvm-svn: 356571

llvm-svn: 356385

Map memory_scope_sub_group to "wavefront" sync scope

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

llvm-svn: 355549

A recent change caused assertion in CodeGenFunction::EmitBlockCallExpr when a block is called.

There is code

  Func = CGM.getOpenCLRuntime().getInvokeFunction(E->getCallee());
getCalleeDecl calls Expr::getReferencedDeclOfCallee, which does not handle
BlockExpr and returns nullptr, which causes isa to assert.

This patch fixes that.

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

llvm-svn: 354893

Summary:
Emit direct call of block invoke functions when possible, i.e. in case the
block is not passed as a function argument.
Also doing some refactoring of `CodeGenFunction::EmitBlockCallExpr()`

Reviewers: Anastasia, yaxunl, svenvh

Reviewed By: Anastasia

Subscribers: cfe-commits

Tags: #clang

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

llvm-svn: 354568

Summary:

For some reason OpenCL blocks in LLVM IR are represented as function pointers.
These pointers do not point to any real function and never get called. Actually
they point to some structure, which in turn contains pointer to the real block
invoke function.
This patch changes represntation of OpenCL blocks in LLVM IR from function
pointers to pointers to `%struct.__block_literal_generic`.
Such representation allows to avoid unnecessary bitcasts and simplifies
further processing (e.g. translation to SPIR-V ) of the module for targets
which do not support function pointers.

Patch by: Alexey Sotkin.

Reviewers: Anastasia, yaxunl, svenvh

Reviewed By: Anastasia

Subscribers: alexbatashev, cfe-commits

Tags: #clang

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

llvm-svn: 354337

Allow all OpenCL types to be parsed in C++ mode.

llvm-svn: 354121

This allows the global visibility controls to be restrictive while still
populating the dynamic symbol table where required.

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

llvm-svn: 353870

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

llvm-svn: 353588

Some of these functions take some extraneous arguments, e.g. EltSize,
Offset, which are computable from the Type and DataLayout.

Add some asserts to ensure that the computed values are consistent
with the passed-in values, in preparation for eliminating the
extraneous arguments. This also asserts that the Type is an Array for
the calls named "Array" and a Struct for the calls named "Struct".

Then, correct a couple of errors:

1. Using CreateStructGEP on an array type. (this causes the majority
   of the test differences, as struct GEPs are created with i32
   indices, while array GEPs are created with i64 indices)

2. Passing the wrong Offset to CreateStructGEP in TargetInfo.cpp on
   x86-64 NACL (which uses 32-bit pointers).

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

llvm-svn: 353529

Fixed typo in the Filecheck directive and changed the
test to verify output correctly.

Fixes PR40029!

llvm-svn: 352760

This reverts r348083. This was based on a misreading of the spec
for printf specifiers.

Also revert r343653, as without a subsequent patch, a correctly
specified format for a vector will incorrectly warn.

Fixes bug 40491.

llvm-svn: 352539

llvm-svn: 352443

Summary:
Added builtins for the interpolation intrinsics, and related LIT
test.

Reviewers: arsenm, tpr, dstuttard, #amdgpu

Reviewed By: arsenm, #amdgpu

Subscribers: kzhuravl, wdng, nhaehnle, yaxunl, dstuttard, tpr, t-tye, cfe-commits

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

llvm-svn: 352358

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

llvm-svn: 350794

Windows doesn't allow common with alignment >32 bits, so these tests
were broken in windows mode.  This patch makes 'common' optional in
these cases.

Change-Id: I4d5fdd07ecdafc3570ef9b09cd816c2e5e4ed15e
llvm-svn: 350645

Summary:
If a function argument is byval and RV is located in default or alloca address space
an optimization of creating addrspacecast instead of memcpy is performed. That is
not correct for OpenCL, where that can lead to a situation of address space casting
from __private * to __global *. See an example below:

```
typedef struct {
  int x;
} MyStruct;

void foo(MyStruct val) {}

kernel void KernelOneMember(__global MyStruct* x) {
  foo (*x);
}
```

for this code clang generated following IR:
...
%0 = load %struct.MyStruct addrspace(1)*, %struct.MyStruct addrspace(1)**
%x.addr, align 4
%1 = addrspacecast %struct.MyStruct addrspace(1)* %0 to %struct.MyStruct*
...

So the optimization was disallowed for OpenCL if RV is located in an address space
different than that of the argument (0).


Reviewers: yaxunl, Anastasia

Reviewed By: Anastasia

Subscribers: cfe-commits, asavonic

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

llvm-svn: 348752

The spec is ambiguous on whether vector types are allowed to be
implicitly converted. The only legal context I think this can
be used for OpenCL is printf, where it seems necessary.

llvm-svn: 348083