[OpenMP] Allow OMP6.0 features. (#122108)

Add support for the `-fopenmp-version=60` command line argument. It is
needed for https://github.com/llvm/llvm-project/pull/119891 (`#pragma
omp stripe`)

[OpenMP] Allow OMP6.0 features. (#122108)

Add support for the `-fopenmp-version=60` command line argument. It is
needed for https://github.com/llvm/llvm-project/pull/119891 (`#pragma
omp stripe`) which will be the first OpenMP 6.0 directive implemented.
Add regression tests for Clang in `-fopenmp-version=60` mode.

show more ...

[OpenMP 5.2] Deprecate syntax of map modifiers without comma separators (#69534)

The syntax of modifiers without comma separators in the map clause was
deprecated in OpenMP 5.2.

Reference: OpenM

[OpenMP 5.2] Deprecate syntax of map modifiers without comma separators (#69534)

The syntax of modifiers without comma separators in the map clause was
deprecated in OpenMP 5.2.

Reference: OpenMP 5.2 Spec, page 627, line 19

show more ...

[OpenMP] Update the default version of OpenMP to 5.1

The default version of OpenMP is updated from 5.0 to 5.1 which means if -fopenmp is specified but -fopenmp-version is not specified with clang, t

[OpenMP] Update the default version of OpenMP to 5.1

The default version of OpenMP is updated from 5.0 to 5.1 which means if -fopenmp is specified but -fopenmp-version is not specified with clang, the default version of OpenMP is taken to be 5.1. After modifying the Frontend for that, various LIT tests were updated. This patch contains all such changes. At a high level, these are the patterns of changes observed in LIT tests -

# RUN lines which mentioned `-fopenmp-version=50` need to kept only if the IR for version 5.0 and 5.1 are different. Otherwise only one RUN line with no version info(i.e. default version) needs to be there.

# Test cases of this sort already had the RUN lines with respect to the older default version 5.0 and the version 5.1. Only swapping the version specification flag `-fopenmp-version` from newer version RUN line to older version RUN line is required.

# Diagnostics: Remove the 5.0 version specific RUN lines if there was no difference in the Diagnostics messages with respect to the default 5.1.

# Diagnostics: In case there was any difference in diagnostics messages between 5.0 and 5.1, mention version specific messages in tests.

# If the test contained version specific ifdef's e.g. "#ifdef OMP5" but there were no RUN lines for any other version than 5.X, then bring the code guarded by ifdef's outside and remove the ifdef's.

# Some tests had RUN lines for both 5.0 and 5.1 versions, but it is found that the IR for 5.0 is not different from the 5.1, therefore such RUN lines are redundant. So, such duplicated lines are removed.

# To generate CHECK lines automatically, use the script llvm/utils/update_cc_test_checks.py

Reviewed By: saiislam, ABataev

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

(cherry picked from commit 9dd2999907dc791136a75238a6000f69bf67cf4e)

show more ...

Add Parse/Sema for iterator for map clause.

[C11/C2x] Change the behavior of the implicit function declaration warning

C89 had a questionable feature where the compiler would implicitly
declare a function that the user called but was never pr

[C11/C2x] Change the behavior of the implicit function declaration warning

C89 had a questionable feature where the compiler would implicitly
declare a function that the user called but was never previously
declared. The resulting function would be globally declared as
extern int func(); -- a function without a prototype which accepts zero
or more arguments.

C99 removed support for this questionable feature due to severe
security concerns. However, there was no deprecation period; C89 had
the feature, C99 didn't. So Clang (and GCC) both supported the
functionality as an extension in C99 and later modes.

C2x no longer supports that function signature as it now requires all
functions to have a prototype, and given the known security issues with
the feature, continuing to support it as an extension is not tenable.

This patch changes the diagnostic behavior for the
-Wimplicit-function-declaration warning group depending on the language
mode in effect. We continue to warn by default in C89 mode (due to the
feature being dangerous to use). However, because this feature will not
be supported in C2x mode, we've diagnosed it as being invalid for so
long, the security concerns with the feature, and the trivial
workaround for users (declare the function), we now default the
extension warning to an error in C99-C17 mode. This still gives users
an easy workaround if they are extensively using the extension in those
modes (they can disable the warning or use -Wno-error to downgrade the
error), but the new diagnostic makes it more clear that this feature is
not supported and should be avoided. In C2x mode, we no longer allow an
implicit function to be defined and treat the situation the same as any
other lookup failure.

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

show more ...

[OPENMP]Redesign of OMPExecutableDirective/OMPDeclarativeDirective representation.

Summary:
Introduced OMPChildren class to handle all associated clauses, statement
and child expressions/statements.

[OPENMP]Redesign of OMPExecutableDirective/OMPDeclarativeDirective representation.

Summary:
Introduced OMPChildren class to handle all associated clauses, statement
and child expressions/statements. It allows to represent some directives
more correctly (like flush, depobj etc. with pseudo clauses, ordered
depend directives, which are standalone, and target data directives).
Also, it will make easier to avoid using of CapturedStmt in directives,
if required (atomic, tile etc. directives).
Also, it simplifies serialization/deserialization of the
executable/declarative directives.
Reduces number of allocation operations for mapper declarations.

Reviewers: jdoerfert

Subscribers: yaxunl, guansong, jfb, cfe-commits, sstefan1, aaron.ballman, caomhin

Tags: #clang

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

show more ...

[OpenMP 5.0] Fix user-defined mapper lookup in sema

This patches fixes the case when a user-defined mapper is attached to
the elements of an array, and to report error when a mapper is used for
type

[OpenMP 5.0] Fix user-defined mapper lookup in sema

This patches fixes the case when a user-defined mapper is attached to
the elements of an array, and to report error when a mapper is used for
types other than struct, class, and union.

Patch by Lingda Li <lildmh@gmail.com>

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

llvm-svn: 373023

show more ...

[OPENMP]Initial support for 'allocate' clause.

Added parsing/sema analysis of the allocate clause.

llvm-svn: 357068

[OpenMP 5.0] Parsing/sema support for from clause with mapper modifier.

This patch implements the parsing and sema support for the OpenMP
'from'-clause with potential user-defined mappers attached.

[OpenMP 5.0] Parsing/sema support for from clause with mapper modifier.

This patch implements the parsing and sema support for the OpenMP
'from'-clause with potential user-defined mappers attached.
User-defined mappers are a new feature in OpenMP 5.0. A 'from'-clause
can have an explicit or implicit associated mapper, which instructs the
compiler to generate and use customized mapping functions. An example is
shown below:

struct S { int len; int *d; };
#pragma omp declare mapper(id: struct S s) map(s, s.d[0:s.len])
struct S ss;
#pragma omp target update from(mapper(id): ss) // use the mapper with name 'id' to map ss from device

Contributed-by: Lingda Li <lildmh@gmail.com>

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

llvm-svn: 354817

show more ...

[OpenMP 5.0] Parsing/sema support for to clause with mapper modifier.

This patch implements the parsing and sema support for OpenMP to clause
with potential user-defined mappers attached. User defin

[OpenMP 5.0] Parsing/sema support for to clause with mapper modifier.

This patch implements the parsing and sema support for OpenMP to clause
with potential user-defined mappers attached. User defined mapper is a
new feature in OpenMP 5.0. A to/from clause can have an explicit or
implicit associated mapper, which instructs the compiler to generate and
use customized mapping functions. An example is shown below:

struct S { int len; int *d; };
#pragma omp declare mapper(id: struct S s) map(s, s.d[0:s.len])
struct S ss;
#pragma omp target update to(mapper(id): ss) // use the mapper with name 'id' to map ss to device

Contributed-by: <lildmh@gmail.com>

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

llvm-svn: 354698

show more ...

[OpenMP 5.0] Parsing/sema support for map clause with mapper modifier.

This patch implements the parsing and sema support for OpenMP map
clauses with potential user-defined mapper attached. User def

[OpenMP 5.0] Parsing/sema support for map clause with mapper modifier.

This patch implements the parsing and sema support for OpenMP map
clauses with potential user-defined mapper attached. User defined mapper
is a new feature in OpenMP 5.0. A map clause can have an explicit or
implicit associated mapper, which instructs the compiler to generate
extra data mapping. An example is shown below:

struct S { int len; int *d; };
#pragma omp declare mapper(id: struct S s) map(s, s.d[0:s.len])
struct S ss;
#pragma omp target map(mapper(id) tofrom: ss) // use the mapper with name 'id' to map ss

Contributed-by: Lingda Li <lildmh@gmail.com>

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

llvm-svn: 354347

show more ...

[OpenMP 5.0] Parsing/sema support for "omp declare mapper" directive.

This patch implements parsing and sema for "omp declare mapper"
directive. User defined mapper, i.e., declare mapper directive,

[OpenMP 5.0] Parsing/sema support for "omp declare mapper" directive.

This patch implements parsing and sema for "omp declare mapper"
directive. User defined mapper, i.e., declare mapper directive, is a new
feature in OpenMP 5.0. It is introduced to extend existing map clauses
for the purpose of simplifying the copy of complex data structures
between host and device (i.e., deep copy). An example is shown below:

struct S { int len; int *d; };
#pragma omp declare mapper(struct S s) map(s, s.d[0:s.len]) // Memory region that d points to is also mapped using this mapper.

Contributed-by: Lingda Li <lildmh@gmail.com>

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

llvm-svn: 352906

show more ...