Page MenuHomePhabricator

[OpenMP][libomptarget] Add math functions support in OpenMP offloading
AbandonedPublic

Authored by gtbercea on Apr 19 2019, 11:10 AM.

Details

Summary

Add kmpc function definition to libomptarget-nvptx.bc.

Event Timeline

gtbercea created this revision.Apr 19 2019, 11:10 AM
ABataev added inline comments.Apr 19 2019, 11:20 AM
libomptarget/deviceRTLs/nvptx/src/interface.h
570

I think you need to add __kmpc_powf(float), __kmpc_powl(long double), __kmpc_sinf(float), __kmpc_sinl(long double)

gtbercea updated this revision to Diff 195920.Apr 19 2019, 2:34 PM
  • Address comments.
gtbercea marked an inline comment as done.Apr 19 2019, 2:34 PM

I guess here, and other places, we will later need to add more function/type combinations. Given that they all follow the same scheme, we should probably use a template for generation soon.

gtbercea updated this revision to Diff 196620.EditedApr 25 2019, 6:05 AM
  • Use macros.
gtbercea retitled this revision from [OpenMP][libomptarget][WIP] Add math functions support in OpenMP offloading to [OpenMP][libomptarget] Add math functions support in OpenMP offloading.Apr 25 2019, 11:07 AM
jdoerfert added inline comments.Apr 29 2019, 6:49 PM
libomptarget/deviceRTLs/nvptx/src/interface.h
585

Shouldn't we do this with macros again?

I would even propose a separate "math_macro.inc" file that is included
in both places. In one the macro DECL_ONLY is set and we get only declarations
while in the other we expand to definitions.
The idea is we simplify the maintenance in the future and cut down code.
Finally, we probably want to reuse the "math_macro.inc" also in other deviceRTLs so
we always support the same functions across all targets. Does that makes sense?

libomptarget/deviceRTLs/nvptx/src/math.cu
21

I was thinking we have some macro for float/double generation:

#define __OPENMP_MATH_FUNC_1_FP(__fn, __kmpc_fn)   \
   __OPENMP_MATH_FUNC_1(float, __fn, __kmpc_fn) \
   __OPENMP_MATH_FUNC_1(double, __fn, __kmpc_fn) \

so we can cut down further below

29

I don't think we want the semicolon at the end.

34

Wouldn't we get the correct conversion for:

`__OPENMP_MATH_FUNC_2(long double, pow, __kmpc_powl);`

If not, should we add a two type version that casts the arguments
and define __OPENMP_MATH_FUNC_2 in terms of that one?

gtbercea abandoned this revision.May 15 2019, 12:54 PM

Replaced by: D61399