The generator expressions should only be used for NVPTX.

LG, might make sense to move these off the device anyway. Fewer things to fail. I'm assuming these all pass as you've written them.

Updating to simply add an entirely new attribute again. The existing
CUDAGlobal attribute does what we want, but it's also highly coupled with the
CUDA language. This made it pretty much impossible to find a way to re-use it
without breaking existing functionality. The amount of code duplicated is
minimal and this is required to be able to emit a callable kernel targeting
NVPTX directly. I'd like to use this for my ongoing GPU libc project so I'd
appreciate someone looking at this again.

LG as long as we can fix it later once the bot picks it up.

Landing this because my build has been broken for the past few hours.

@tra would it be possible to go to the earlier version that simply duplicated a slight amount of logic to introduce the new and separate attribute nvptx_kernel? Overloading CUDA's device attribute is problematic because it's used and checked in several different contexts. I'd like to be able to simplify this code https://github.com/llvm/llvm-project/blob/main/libc/startup/gpu/nvptx/start.cpp.

This was committed externally and I forgot to link it up.

Checking allocation return values.

Return nullptr early if the allocation returns null.

Forgot to check errors on the AMD implementation.

Addressing comments.

In D146725#4216704, @tianshilei1992 wrote:

Does it have to be sys? Does gl (kernel level) work?

Moving device copying functions into a common utility.

If you include Fixes: <bug url> in the commit message it'll automatically close it by the way.

LG

We should have a clang test as well

Hopefully this works.

I can commandeer tomorrow

In D142514#4206591, @DavidSpickett wrote:

This is probably a very late report but I happened to be looking at openmp bots for a different reason, some of the error returns in this change are failing to compile:
https://lab.llvm.org/buildbot/#/builders/4/builds/32052/steps/5/logs/stdio

Despite the "gcc" name, this bot appears to use clang-11 which is still supported for building llvm.

This is a simplified version: https://godbolt.org/z/x91h9KcGq

I'm not sure how we're expected to use Expected (no pun intended) in this scenario. There is probably a helper function somewhere.

In D142514#4206591, @DavidSpickett wrote:

This is probably a very late report but I happened to be looking at openmp bots for a different reason, some of the error returns in this change are failing to compile:
https://lab.llvm.org/buildbot/#/builders/4/builds/32052/steps/5/logs/stdio

Despite the "gcc" name, this bot appears to use clang-11 which is still supported for building llvm.

This is a simplified version: https://godbolt.org/z/x91h9KcGq

I'm not sure how we're expected to use Expected (no pun intended) in this scenario. There is probably a helper function somewhere.

Remove whitespace

In D146256#4202584, @JonChesterfield wrote:

Global ctor/dtor is tricky. I have a suspicion hip and openmp have done different things there. When to run the dtor is a challenge, and how many threads the ctors run with may have implementation divergence.

Changing message

Addressing comments

Updating, error message now looks like this.

We should only set the special libc.utils.gpu.loader target once for the target under test.

LGTM, it's much simpler for now since Flang doesn't support CUDA, HIP, OpenCL, OpenMP, etc.

Addressing comments

Merging the dependency list and addressing comments. I'll try to remove the other dependencies by picking them up from the startup in a later patch.