This header is not part of `clangBasic`'s interface, but rather its implementation (`lib/Basic` rather than `include/clang/Basic`). Sema can't depend on it - if you need to use its APIs from outside clangBasic they should be moved to a public header. The bazel build shows the problem: https://buildkite.com/llvm-project/upstream-bazel/builds/75928#018ad568-2f7c-4dda-ae90-3b4d787caad7. Breaking bazel is not itself reason to revert, but here it's flagging a real problem that CMake doesn't catch. I've reverted as 0afbcb20fd908f8bf9073697423da097be7db592 - sorry to do this so abruptly, but I can't fix this myself & such problems block downstream use of LLVM.

Do we want to ignore this directive if the metadata exists, but we're targeting a pre-sm_90 GPU? It may be useful for non-clang LLVM users (e.g XLA) to be able to always specify launch bounds metadata, and let LLVM decide on what it can do with it. Generating the directive for older GPUs would result in ptxas error, while ignoring it would still allow the kernels to compile and work, the same as would be the case if the metadata was correctly absent. I don't think there's not much point to require users to jump through more hoops just to achieve exactly the same result.

Considering that we do have TargetInfo pointer here, instead of trying to figure out the target GPU via features, can we just extract CudaArch directly from [NVPTXTargetInfo::GPU](https://github.com/llvm/llvm-project/blob/7fcbb64fca5e664b11f9167a215b47de2ae9082c/clang/lib/Basic/Targets/NVPTX.h#L65C3-L65C12) ?

Are we ignoring the whole launch_bounds attribute, or only the MaxBlocks parameter?

Do we have enough information to assert this is non-negative?