Introduce support of the LLVM SPIR-V Backend to translate LLVM IR to SPIR-V

[VyacheslavLevytskyy]

This PR is to introduce support of the LLVM SPIR-V Backend to translate LLVM IR to SPIR-V. The backend will be preferred over Khronos Translator only when both conditions are satisfied:

• the SPIR-V Backend is present in the deployment of LLVM,
• there is an environmental variable TRITON_USE_SPIRV_BACKEND present and set to a non-zero integer value.

Khronos Translator remains the default tool to translate LLVM IR to SPIR-V.

[etiotto]

Would be interesting to see what is the functional pass rate after switching to use the official LLVM SPIRV BE.

[VyacheslavLevytskyy]

Would be interesting to see what is the functional pass rate after switching to use the official LLVM SPIRV BE.

Just a point to remember that we will not see actual pass rates in the CI -- active development means that CI results are always outdated.

[whitneywhtsang]

When would SPIRV backend not exists after SPIRV backend moved out of experimental?

[VyacheslavLevytskyy]

I'm not 100% until I check, but I'd expect that, for example, LLVM_TARGETS_TO_BUILD allows to narrow a list of targets and exclude any existing target from actually installed.

[etiotto]

Suggested change

	"--spirv-ext=all", "- O3"};
	"--spirv-ext=all", "-O3"};

[VyacheslavLevytskyy]

A fun fact is that "- O3" is a legit option to pass in a legacy SPIR-V Backend API call. Please see a comment in lines 22-31 of third_party/intel/lib/Target/SPIRV/SPIRVTranslation.cpp for a wider perspective of how we are going to switch to a newer API call when it's available in openai llvm build.

In brief, this "- O3" will disappear in favor of explicit CodeGenOptLevel::Aggressive. For now, though, llvm has -O reserved for itself, so SPIR-V Backend API engaged a slightly weird spelling of - O to be able to pass opt level into the API call in a style of command line arguments. Appreciate your attention to these details in the review!

[whitneywhtsang]

FYI @VyacheslavLevytskyy, LLVM commit is updated in #3316, it now contains llvm/llvm-project@cda81b1.

[VyacheslavLevytskyy]

FYI @VyacheslavLevytskyy, LLVM commit is updated in #3316, it now contains llvm/llvm-project@cda81b1.

Thank you @whitneywhtsang , this simplifies the patch even further, updated.

[VyacheslavLevytskyy]

@whitneywhtsang Looks like pre-built LLVM used by failed Github Actions doesn't contain SPIRV as a target.

In scripts/compile-triton.sh we are able to explicitly list targets via -DLLVM_TARGETS_TO_BUILD="X86;NVPTX;AMDGPU;SPIRV". What should be updated to avoid the following complaint?

  CMake Error at /home/runner/.triton/llvm/llvm-c1188642-ubuntu-x64/lib/cmake/llvm/LLVM-Config.cmake:271 (message):
    Library 'SPIRVCodeGen' is a direct reference to a target library for an
    omitted target.

@pbchekin Can you please suggest what else should be updated for the prebuilt /home/runner/.triton/llvm/ to be configured according to -DLLVM_TARGETS_TO_BUILD="X86;NVPTX;AMDGPU;SPIRV" ?

[pbchekin]

@pbchekin Can you please suggest what else should be updated for the prebuilt /home/runner/.triton/llvm/ to be configured according to -DLLVM_TARGETS_TO_BUILD="X86;NVPTX;AMDGPU;SPIRV" ?

We currently use LLVM prebuilt by OpenAI (https://github.com/triton-lang/triton/blob/main/.github/workflows/llvm-build.yml), not sure if they are ready to add SPIRV target right now to their build workflow. So we have two options:

• Start using our own llvm builds with SPIRV target. We did this in the past so it is possible.
• Update this PR to detect if llvm has SPIRV target or to introduce a build-time option so we can continue using the existing OpenAI builds and use a custom built llvm with SPIRV in a special CI workflow that I am going to add shortly.

[VyacheslavLevytskyy]

@pbchekin Can you please suggest what else should be updated for the prebuilt /home/runner/.triton/llvm/ to be configured according to -DLLVM_TARGETS_TO_BUILD="X86;NVPTX;AMDGPU;SPIRV" ?

We currently use LLVM prebuilt by OpenAI (https://github.com/triton-lang/triton/blob/main/.github/workflows/llvm-build.yml), not sure if they are ready to add SPIRV target right now to their build workflow. So we have two options:

• Start using our own llvm builds with SPIRV target. We did this in the past so it is possible.
• Update this PR to detect if llvm has SPIRV target or to introduce a build-time option so we can continue using the existing OpenAI builds and use a custom built llvm with SPIRV in a special CI workflow that I am going to add shortly.

Good point, thank you. Then I revert back to the initial logic that doesn't rely and always checks presence of SPIR-V Backend.