I'd add a comment with a brief explanation for the const variant and a TODO() to remove it.

LGTM.

In D61765#1500457, @gtbercea wrote:

This won't affect CUDA in any way, all we have added is OpenMP specific.

In D61765#1500309, @gtbercea wrote:

As soon as libc++ the limits header included in

__clang_cuda_cmath.h:15
``` is not found:

__clang_cuda_cmath.h:15:10: fatal error: 'limits' file not found
#include <limits>

Not even CUDA works actually so I'm not sure what the best answer to this problem is.

In D61765#1499957, @jdoerfert wrote:

Two small changes and then it is fine with me. @tra ?

In D61458#1488550, @hliao wrote:

In D61458#1488523, @tra wrote:

Perhaps we should allow this in all unevaluated contexts?
I.e. int s = sizeof(foo(x)); should also work.

good point, do we have a dedicated context for sizeof? that make the checking easier.

Perhaps we should allow this in all unevaluated contexts?
I.e. int s = sizeof(foo(x)); should also work.

LGTM, but I've added @rsmith who is way more familiar with this code.

In D60907#1484756, @jdoerfert wrote:

I actually don't want to preinclude anything and my arguments are (mostly) for the OpenMP offloading code path not necessarily Cuda.
Maybe to clarify, what I want is:

1. Make sure the clang/Headers/math.h is found first if math.h is included.
2. Use a scheme similar to the one described https://reviews.llvm.org/D47849#1483653 in clang/Headers/math.h
3. Only add math.h function overloads in our math.h. <- This is debatable

+1 to Hal's comments.

A kernel functions in CUDA is actually two different functions. One is the real kernel we compile for the GPU, another is a host-side stub that launches the device-side kernel.

FYI, I have almost-ready set of patches to implement missing bits of sm_75 support, including this change:
https://reviews.llvm.org/D60279

LGTM. Thank you for cleaning this up.

In D60727#1467241, @echristo wrote:

Nick: Can you do some archaeology on the original patch and find out if there was supposed to be something supported here?

Art: Any thoughts?

@arsenm Matt, FYI, this patch seems to be a continuation of D59863 you've commented on.

It looks like you are solving two problems here.
a) you want to create multiple device passes for the same GPU, but with different options.
b) you may want to pass different compiler options to different device compilations.
The patch effectively hard-codes {gpu, options} tuple into --offloading-target-id variant.
Is that correct?

• Converted class to struct+function as Tim suggested.

In D60220#1456430, @emankov wrote:

Oooh, sorry, but I've just pushed the fix. But with the following words: "Add missing long double device functions' declarations. Provide only declarations to prevent any use of long double on the device side, because CUDA does not support long double on the device side."

One more thing -- perhaps the long double declarations should be put under #ifndef _MSC_VER in all the files to make the change unobservable on non-windows platforms.

Thank you for fixing this!

• Added PTX64 to the list of builtins' constraints.

• Fixed minor issues with parameters of the new builtins:
  • __imma*_st_c_i32 builtins have 'const int * src'
  • __bmma_m8n8k128_mma_xor_popc_b1 does not have 'satf' argument.

Cleaned up mma test generation.

• Enabled .satf for s4/u4.

In D60141#1452019, @ashi1 wrote:

Hi Artem, I had just committed the change. IS this change OK or should I revert it?

General nit: please use diffs with very large context when you submit patches with Phabricator.
https://llvm.org/docs/Phabricator.html#requesting-a-review-via-the-web-interface

@rsmith, @jlebar I'm out of my depth here and could use some language lawyering help.

I am unsure whether the problem with the build system as referred to by the remark "switch to -pthread once the rest of the build system can deal with it" is now solved, though. @tra, any idea?

This looks like one of the things we should *not* do as it affects correctness -- non-trivial constructor may be arbitrarily complex and the per-TU flag to enable this behavior is way too coarse, IMO.
On the other hand, I can believe that someone somewhere did write the code and relies to NVCC accepting it.

This is, or is very similar to, the problem that the host/device overloading addresses in CUDA.

Rebased on updated D59389

• Addressed Tim's comments.

• Addressed Tim's comments.

The intent is to avoid unintentional clashes with the preprocessor macros the user may have defined.
https://reviews.llvm.org/rL260647

In D59423#1431151, @emankov wrote:

Perhaps for consistency sake it would be better to replace __sptr -> __s and __cptr -> __c.

Well, it came from NVIDIA code, you know, I mean all those double underscores.

___ stands out as a sore thumb and raises unnecessary questions -- "why does it have three underscores, while __cptr is fine with two?".
Perhaps for consistency sake it would be better to replace __sptr -> __s and __cptr -> __c.
Given that we're just passing the args through, we don't really need to have ptr here.