[llvm] [SPIR-V] Add pre-commit CI workflow (PR #74092)

[Natalie Chouinard via llvm-commits]

================
@@ -0,0 +1,28 @@
+name: SPIR-V Tests
+
+permissions:
+  contents: read
+
+on:
+  workflow_dispatch:
+  pull_request:
+    paths:
+      - 'llvm/lib/Target/SPIRV/**'
+      - 'llvm/test/CodeGen/SPIRV/**'
+      - '.github/workflows/spirv-tests.yml'
+
+concurrency:
+  # Skip intermediate builds: always.
+  # Cancel intermediate builds: only if it is a pull request build.
+  group: ${{ github.workflow }}-${{ github.ref }}
+  cancel-in-progress: ${{ startsWith(github.ref, 'refs/pull/') }}
+
+jobs:
+  check_spirv:
+    if: github.repository_owner == 'llvm'
+    name: Test SPIR-V
+    uses: ./.github/workflows/llvm-project-tests.yml
+    with:
+      build_target: check-llvm-codegen-spirv
+      projects: clang
+      experimental_targets: SPIRV
----------------
sudonatalie wrote:

@tstellar Thanks for taking a look!

> We depend a lot on ccache to get faster builds, do you know if adding `DLLVM_EXPERIMENTAL_TARGETS_TO_BUILD=spirv` makes any changes to header files that may invalidate the ccache data?

Do you have any suggestions for how I'd go about checking this? I've never used ccache before, but I just ran a couple tests with it using separate clean build directories and `-DCMAKE_CXX_COMPILER=/usr/lib/ccache/clang++ -DCMAKE_C_COMPILER=/usr/lib/ccache/clang` but the builds take ~the same time with the same CMake args regardless of whether the cache is cleaned or populated.

> Would it make sense to start by having this job manually triggered either by a comment or a label?

In my opinion, I think the benefit of these checks would be that they'd run automatically, so people touching SPIR-V backend files get that feedback on their PR even if they forget/don't know that this bot exists. However, I understand we're using shared resources here, so if a manual trigger is a necessary compromise to start with then I'd certainly rather that than nothing.

> How important is it to run this job on Windows and Mac OS? We are resource constrained on those OSes.

Much less important since the behavior shouldn't diverge on different platforms, so Linux only is fine. Still working on figuring out how to configure that with GitHub actions though, my first several attempts to override `runs-on` from the calling workflow were unsuccessful so I'm going to try to find a better way to test it than repeatedly force-pushing here.

https://github.com/llvm/llvm-project/pull/74092