[clang] Use value_or instead of getValueOr (NFC)

[AMDGPU][clang] Definition of gfx11 subtarget

Contributors:
Jay Foad <[email protected]>
Konstantin Zhuravlyov <[email protected]>

Patch 2/N for upstreaming of AMDGPU gfx11 architecture

Depe

[AMDGPU][clang] Definition of gfx11 subtarget

Contributors:
Jay Foad <[email protected]>
Konstantin Zhuravlyov <[email protected]>

Patch 2/N for upstreaming of AMDGPU gfx11 architecture

Depends on D124536

Reviewed By: foad, kzhuravl, #amdgpu, arsenm

Differential Revision: https://reviews.llvm.org/D124537

show more ...

[AMDGPU] Add gfx1036 target

Differential Revision: https://reviews.llvm.org/D120846

[AMDGPU] Add gfx940 target

This is target definition only.

Differential Revision: https://reviews.llvm.org/D120688

[HIPSPV][3/4] Enable SPIR-V emission for HIP

This patch enables SPIR-V binary emission for HIP device code via the
HIPSPV tool chain.

‘--offload’ option, which is envisioned in [1], is added for sp

[HIPSPV][3/4] Enable SPIR-V emission for HIP

This patch enables SPIR-V binary emission for HIP device code via the
HIPSPV tool chain.

‘--offload’ option, which is envisioned in [1], is added for specifying
offload targets. This option is used to override default device target
(amdgcn-amd-amdhsa) for HIP compilation for emitting device code as
SPIR-V binary. The option is handled in getHIPOffloadTargetTriple().

getOffloadingDeviceToolChain() function (based on the design in the
SYCL repository) is added to select HIPSPVToolChain when HIP offload
target is ‘spirv64’.

The HIPActionBuilder is modified to produce LLVM IR at the backend
phase. HIPSPV tool chain expects to receive HIP device code as LLVM
IR so it can run external LLVM passes over them. HIPSPV TC is also
responsible for emitting the SPIR-V binary.

A Cuda GPU architecture ‘generic’ is added. The name is picked from
the LLVM SPIR-V Backend. In the HIPSPV code path the architecture
name is inserted to the bundle entry ID as target ID. Target ID is
expected to be always present so a component in the target triple
is not mistaken as target ID.

Tests are added for checking the HIPSPV tool chain.

[1]: https://lists.llvm.org/pipermail/cfe-dev/2020-December/067362.html

Patch by: Henry Linjamäki

Reviewed by: Yaxun Liu, Artem Belevich, Alexey Bader

Differential Revision: https://reviews.llvm.org/D110622

show more ...

[CUDA] Bump supported CUDA version to 11.5

Differential Revision: https://reviews.llvm.org/D113249

[CUDA] Improve CUDA version detection and diagnostics.

Always use cuda.h to detect CUDA version. It's a more universal approach
compared to version.txt which is no longer present in recent CUDA vers

[CUDA] Improve CUDA version detection and diagnostics.

Always use cuda.h to detect CUDA version. It's a more universal approach
compared to version.txt which is no longer present in recent CUDA versions.

Split the 'unknown CUDA version' warning in two:

* when detected CUDA version is partially supported by clang. It's expected to
work in general, at the feature parity with the latest supported CUDA
version. and may be missing support for the new features/instructions/GPU
variants. Clang will issue a warning.

* when detected version is new. Recent CUDA versions have been working with
clang reasonably well, and will likely to work similarly to the partially
supported ones above. Or it may not work at all. Clang will issue a warning and
proceed as if the latest known CUDA version was detected.

Differential Revision: https://reviews.llvm.org/D108247

show more ...

[CUDA] Add support for CUDA-11.4

Differential Revision: https://reviews.llvm.org/D108239

[AMDGPU] Add gfx1035 target

Differential Revision: https://reviews.llvm.org/D104804

Reland "[AMDGPU] Add gfx1013 target"

This reverts commit 211e584fa2a4c032e4d573e7cdbffd622aad0a8f.

Fixed a use-after-free error that caused the sanitizers to fail.

Revert "[AMDGPU] Add gfx1013 target"

This reverts commit ea10a86984ea73fcec3b12d22404a15f2f59b219.

A sanitizer buildbot reports an error.

[AMDGPU] Add gfx1013 target

Differential Revision: https://reviews.llvm.org/D103663

[AMDGPU] Add gfx1034 target

Differential Revision: https://reviews.llvm.org/D102306

[Cuda] Internalize a struct and a global variable

[AMDGPU] gfx90a support

Differential Revision: https://reviews.llvm.org/D96906

[CUDA, NVPTX] Allow targeting sm_86 GPUs.

The patch only plumbs through the option necessary for targeting sm_86 GPUs w/o
adding any new functionality.

Differential Revision: https://reviews.llvm.o

[CUDA, NVPTX] Allow targeting sm_86 GPUs.

The patch only plumbs through the option necessary for targeting sm_86 GPUs w/o
adding any new functionality.

Differential Revision: https://reviews.llvm.org/D95974

show more ...

[NFC][AMDGPU] Reformat AMD GPU targets in cuda.cpp

Differential Revision: https://reviews.llvm.org/D93181

[AMDGPU] Add gfx1033 target

Differential Revision: https://reviews.llvm.org/D90447

Change-Id: If2650fc7f31bbdd49c76e74a9ca8e3734d769761

[AMDGPU] Add gfx90c target

This differentiates the Ryzen 4000/4300/4500/4700 series APUs that were
previously included in gfx909.

Differential Revision: https://reviews.llvm.org/D90419

Change-Id:

[AMDGPU] Add gfx90c target

This differentiates the Ryzen 4000/4300/4500/4700 series APUs that were
previously included in gfx909.

Differential Revision: https://reviews.llvm.org/D90419

Change-Id: Ia901a7157eb2f73ccd9f25dbacec38427312377d

show more ...

[AMDGPU] Add gfx602, gfx705, gfx805 targets

At AMD, in an internal audit of our code, we found some corner cases
where we were not quite differentiating targets enough for some old
hardware. This co

[AMDGPU] Add gfx602, gfx705, gfx805 targets

At AMD, in an internal audit of our code, we found some corner cases
where we were not quite differentiating targets enough for some old
hardware. This commit is part of fixing that by adding three new
targets:

* The "Oland" and "Hainan" variants of gfx601 are now split out into
gfx602. LLPC (in the GPUOpen driver) and other front-ends could use
that to avoid using the shaderZExport workaround on gfx602.

* One variant of gfx703 is now split out into gfx705. LLPC and other
front-ends could use that to avoid using the
shaderSpiCsRegAllocFragmentation workaround on gfx705.

* The "TongaPro" variant of gfx802 is now split out into gfx805.
TongaPro has a faster 64-bit shift than its former friends in gfx802,
and a subtarget feature could be set up for that to take advantage of
it. This commit does not make that change; it just adds the target.

V2: Add clang changes. Put TargetParser list in order.
V3: AMDGCNGPUs table in TargetParser.cpp needs to be in GPUKind order,
so fix the GPUKind order.

Differential Revision: https://reviews.llvm.org/D88916

Change-Id: Ia901a7157eb2f73ccd9f25dbacec38427312377d

show more ...

[CUDA][HIP] Fix bound arch for offload action for fat binary

Currently CUDA/HIP toolchain uses "unknown" as bound arch
for offload action for fat binary. This causes -mcpu or -march
with "unknown" a

[CUDA][HIP] Fix bound arch for offload action for fat binary

Currently CUDA/HIP toolchain uses "unknown" as bound arch
for offload action for fat binary. This causes -mcpu or -march
with "unknown" added in HIPToolChain::TranslateArgs or
CUDAToolChain::TranslateArgs.

This causes issue for https://reviews.llvm.org/D88377 since
HIP toolchain needs to check -mcpu in HIPToolChain::TranslateArgs.

The bound arch of offload action for fat binary is not really
used, therefore set it to CudaArch::UNUSED.

Differential Revision: https://reviews.llvm.org/D88524

show more ...

[HIP] Add gfx1031 and gfx1030

Differential Revision: https://reviews.llvm.org/D87324

[CUDA] Fix missed CUDA version mappings.

[CUDA] Add partial support for recent CUDA versions.

Generate PTX using newer versions of PTX and allow using sm_80 with CUDA-11.
None of the new features of CUDA-10.2+ have been implemented yet, so

[CUDA] Add partial support for recent CUDA versions.

Generate PTX using newer versions of PTX and allow using sm_80 with CUDA-11.
None of the new features of CUDA-10.2+ have been implemented yet, so using these
versions will still produce a warning.

Differential Revision: https://reviews.llvm.org/D77670

show more ...

[CUDA] Simplify GPU variant handling. NFC.

Instead of hardcoding individual GPU mappings in multiple functions, keep them
all in one table and use it to look up the mappings.

We also don't care abo

[CUDA] Simplify GPU variant handling. NFC.

Instead of hardcoding individual GPU mappings in multiple functions, keep them
all in one table and use it to look up the mappings.

We also don't care about 'virtual' architecture much, so the API is trimmed down
down to a simpler GPU->Virtual arch name lookup.

Differential Revision: https://reviews.llvm.org/D77665

show more ...