Commit Graph

7 Commits

Author SHA1 Message Date
Johannes Doerfert befb4be3a8 [OpenMP] `omp begin/end declare variant` - part 2, sema ("+CG")
This is the second part loosely extracted from D71179 and cleaned up.

This patch provides semantic analysis support for `omp begin/end declare
variant`, mostly as defined in OpenMP technical report 8 (TR8) [0].
The sema handling makes code generation obsolete as we generate "the
right" calls that can just be handled as usual. This handling also
applies to the existing, albeit problematic, `omp declare variant
support`. As a consequence a lot of unneeded code generation and
complexity is removed.

A major purpose of this patch is to provide proper `math.h`/`cmath`
support for OpenMP target offloading. See PR42061, PR42798, PR42799. The
current code was developed with this feature in mind, see [1].

The logic is as follows:

If we have seen a `#pragma omp begin declare variant match(<SELECTOR>)`
but not the corresponding `end declare variant`, and we find a function
definition we will:
  1) Create a function declaration for the definition we were about to generate.
  2) Create a function definition but with a mangled name (according to
     `<SELECTOR>`).
  3) Annotate the declaration with the `OMPDeclareVariantAttr`, the same
     one used already for `omp declare variant`, using and the mangled
     function definition as specialization for the context defined by
     `<SELECTOR>`.

When a call is created we inspect it. If the target has an
`OMPDeclareVariantAttr` attribute we try to specialize the call. To this
end, all variants are checked, the best applicable one is picked and a
new call to the specialization is created. The new call is used instead
of the original one to the base function. To keep the AST printing and
tooling possible we utilize the PseudoObjectExpr. The original call is
the syntactic expression, the specialized call is the semantic
expression.

[0] https://www.openmp.org/wp-content/uploads/openmp-TR8.pdf
[1] https://reviews.llvm.org/D61399#change-496lQkg0mhRN

Reviewers: kiranchandramohan, ABataev, RaviNarayanaswamy, gtbercea, grokos, sdmitriev, JonChesterfield, hfinkel, fghanim, aaron.ballman

Subscribers: bollu, guansong, openmp-commits, cfe-commits

Tags: #clang

Differential Revision: https://reviews.llvm.org/D75779
2020-03-27 02:30:58 -05:00
Alexey Bataev adc38dcf5f [OPENMP50]Fix scoring of contexts with and without user provided scores.
The context selector with user provided score must have higher score
than the context selector without user provided score.

llvm-svn: 374224
2019-10-09 20:54:06 +00:00
Alexey Bataev 303657a6c6 [OPENMP50]Multiple vendors in vendor context must be treated as logical
and of vendors, not or.

If several vendors are provided in the same vendor context trait, the
context shall match only if all vendors are matching, not one of them.
This is per OpenMP 5.0, 2.3.3 Matching and Scoring Context Selectors,
all selectors in the construct, device, and implementation sets of the
context selector appear in the corresponding trait set of the OpenMP
context.

llvm-svn: 374107
2019-10-08 19:44:16 +00:00
Alexey Bataev 6b06ead19b [OPENMP50]Allow functions in declare variant directive to have different
C linkage.

After some discussion with OpenMP developers, it was decided that the
functions with the different C linkage can be used in declare variant
directive.

llvm-svn: 374057
2019-10-08 14:56:20 +00:00
Alexey Bataev a92b5309e5 [OPENMP]Fix the test on Windows, NFC.
llvm-svn: 373672
2019-10-03 22:10:33 +00:00
Alexey Bataev 0364c760ad [OPENMP50]Codegen support for scores in context selectors.
If the context selector has associated score and several contexts
selectors matches current context, the function with the highest score
must be selected.

llvm-svn: 373661
2019-10-03 20:49:48 +00:00
Alexey Bataev 2df5f12ea1 [OPENMP50]Initial codegen for declare variant implementation vendor.
Initial implementation of global aliases emission for the declare
variant pragma with implementation vendor context selector set.

llvm-svn: 373387
2019-10-01 20:18:32 +00:00