[Clang] diagnosing missing Vulkan environment when using SPIR-V triple

[PrabbyDD]

When a user passes '-target spirv' without specififying a vulkan environment ttriple, SPIRVTargetInfo will fire an assert instead of throwing an error diagnostic. Added this diagnostic in CompilerInstance::createTarget() before target is initialized. Fixes #189964

[github-actions]

Thank you for submitting a Pull Request (PR) to the LLVM Project!

This PR will be automatically labeled and the relevant teams will be notified.

If you wish to, you can add reviewers by using the "Reviewers" section on this page.

If this is not working for you, it is probably because you do not have write permissions for the repository. In which case you can instead tag reviewers by name in a comment by using @ followed by their GitHub username.

If you have received no comments on your PR for a week, you can request a review by "ping"ing the PR by adding a comment “Ping”. The common courtesy "ping" rate is once a week. Please remember that you are asking for valuable time from other developers.

If you have further questions, they may be answered by the LLVM GitHub User Guide.

You can also ask questions in a comment on this PR, on the LLVM Discord or on the forums.

[llvmbot]

@llvm/pr-subscribers-clang

@llvm/pr-subscribers-clang-driver

Author: PrabbyDD

Changes

Fixes issue #189964

---

Full diff: https://github.com/llvm/llvm-project/pull/190840.diff

3 Files Affected:

• (modified) clang/include/clang/Basic/DiagnosticFrontendKinds.td (+3)
• (modified) clang/lib/Frontend/CompilerInstance.cpp (+11)
• (added) clang/test/Driver/spirv-target-validation.c (+4)

diff --git a/clang/include/clang/Basic/DiagnosticFrontendKinds.td b/clang/include/clang/Basic/DiagnosticFrontendKinds.td
index 62b74574102e4..0a3e4e82a79e5 100644
--- a/clang/include/clang/Basic/DiagnosticFrontendKinds.td
+++ b/clang/include/clang/Basic/DiagnosticFrontendKinds.td
@@ -43,6 +43,9 @@ def note_fe_backend_resource_limit: Note<"%0 (%1) exceeds limit (%2) in '%3'">,
 def remark_fe_backend_plugin: Remark<"%0">, BackendInfo, InGroup<RemarkBackendPlugin>;
 def note_fe_backend_plugin: Note<"%0">, BackendInfo;
 
+def err_spirv_requires_vulkan : Error<
+    "SPIR-V target requires a Vulkan environment (e.g. '-target spirv64-unknown-vulkan1.3')">;
+
 def warn_fe_override_module : Warning<
     "overriding the module target triple with %0">,
     InGroup<DiagGroup<"override-module">>;
diff --git a/clang/lib/Frontend/CompilerInstance.cpp b/clang/lib/Frontend/CompilerInstance.cpp
index 0b00ad7128c00..89898d3adfbae 100644
--- a/clang/lib/Frontend/CompilerInstance.cpp
+++ b/clang/lib/Frontend/CompilerInstance.cpp
@@ -112,6 +112,17 @@ void CompilerInstance::setTarget(TargetInfo *Value) { Target = Value; }
 void CompilerInstance::setAuxTarget(TargetInfo *Value) { AuxTarget = Value; }
 
 bool CompilerInstance::createTarget() {
+
+  // Validate Vulkan environment for SPIRV. 
+  llvm::Triple Triple(getInvocation().getTargetOpts().Triple);
+  if (Triple.getArch() == llvm::Triple::spirv) {
+    if (Triple.getOS() != llvm::Triple::Vulkan ||
+        Triple.getVulkanVersion() == llvm::VersionTuple(0)) {
+      getDiagnostics().Report(diag::err_spirv_requires_vulkan) << Triple.str();
+      return false;
+    }
+  }
+
   // Create the target instance.
   setTarget(TargetInfo::CreateTargetInfo(getDiagnostics(),
                                          getInvocation().getTargetOpts()));
diff --git a/clang/test/Driver/spirv-target-validation.c b/clang/test/Driver/spirv-target-validation.c
new file mode 100644
index 0000000000000..cde5b46c54b94
--- /dev/null
+++ b/clang/test/Driver/spirv-target-validation.c
@@ -0,0 +1,4 @@
+// RUN: %clang -target spirv %s 2>&1 | FileCheck %s
+// CHECK: error: SPIR-V target requires a Vulkan environment
+
+int main() { return 0; }
\ No newline at end of file

[PrabbyDD]

Hello! This is my first PR to LLVM. A small diagnostics fix. If there is any advice for newbie mistakes I might have made, I will gladly fix them. I am trying to work my way up from smaller issues to larger ones in clang because it is complex. I tried to include short but meaningful comments in the code, a unit test that mimics others I saw, and meaningful commit messages. Thanks.

[github-actions]

✅ With the latest revision this PR passed the C/C++ code formatter.

[github-actions]

🐧 Linux x64 Test Results

• 115490 tests passed
• 4603 tests skipped

✅ The build succeeded and all tests passed.

[github-actions]

🪟 Windows x64 Test Results

• 55295 tests passed
• 2455 tests skipped

✅ The build succeeded and all tests passed.

[to268]

You should not format code (manually or automatically) outside of your changes. It makes it harder to review your PR.

[PrabbyDD]

You should not format code (manually or automatically) outside of your changes. It makes it harder to review your PR.

Can you elaborate what you mean by this? I attached the clang formatter to my VSCode settings file now so that when I saw it automatically formats, is that not something I should be doing?

[to268]

You should not format code (manually or automatically) outside of your changes. It makes it harder to review your PR.

Can you elaborate what you mean by this? I attached the clang formatter to my VSCode settings file now so that when I saw it automatically formats, is that not something I should be doing?

What I was saying was you should not format the entire file you are editing, only the parts of the code you have changed. In this case it is better to disable auto formatting in your settings. You can either manually format each part of your changes by selecting one area and use the format feature on it or format what ends up in the diff using one of the appropriate script in the clang-format tools directory.

The format job checks only the formatting of what you have changed anyways, not the entire file you have modified.

[to268]

I would also rewrite the title of the PR by adding a tag of on which sub project this PR is mainly touching (which in this case would be prepending the PR title with [Clang]), rewording the title by adding a bit more detailed like diagnosing missing Vulkan environment when using SPIR-V triple, and remove the issue number at the end.
Also, remove the first line of the description (since it is already mentioned at the end with the Fixes #XXX). Your current description is descriptive enough, so there is no need to improve it.
There is no developer policy on it, but it is good practice to better describe what the commit is doing (which is the PR title and and description (fist message of the PR) that ends up in the commit message).

[PrabbyDD]

Ok I should have removed the formatting changes on the whole file and just applied it to my changes, and I retested it on my end and it triggered the error, in addition to making the title changes. If there is something else please let me know.

[to268]

The only thing remaining outside of the PR itself is adding a line in the ReleaseNotes.rst (in the Clang sub directory in this case) in the appropriate section that is used to describe changes for each release.
I will reach out to the lead maintainer of Clang privately so he can assign the right people to review the SPIR-V specific part of the PR (since he has not done that already).

[to268]

I have a broader concern outside of the highlighted changes.
I do not know the Frontend and the Driver area well, so this would need to be confirmed by someone who knows better before implementing what I will be suggesting below.

I think the check and the diagnostic should be moved from the Frontend part to the Driver part because we have already a similar diagnostic for HLSL in CompilerInvocation.cpp. Moreover, at this stage, we already have a triple object constructed for checks based on the triple.

The test case would also look like the empty Vulkan environment test for HLSL

The only reason to place the check in CompilerInstance.cpp would be to diagnose it earlier.

[AaronBallman]

Thank you for working on this! Please be sure to add a release note to clang/docs/ReleaseNotes.rst so users know about the fix.

[to268]

There are a few things to fix.

[AaronBallman]

I think at least part of the testing issue is that you're running the driver (clang) rather than the frontend (clang -cc1).

[to268]

I would wait a bit before triggering a new build since someone broke an LLDB test (there is no way that patch breaks it):

  Failed Tests (1):
    lldb-api :: tools/lldb-dap/variables/TestDAP_variables.py

[AaronBallman]

LGTM!

[to268]

LGTM too!

[github-actions]

@PrabbyDD Congratulations on having your first Pull Request (PR) merged into the LLVM Project!

Your changes will be combined with recent changes from other authors, then tested by our build bots. If there is a problem with a build, you may receive a report in an email or a comment on this PR.

Please check whether problems have been caused by your change specifically, as the builds can include changes from many authors. It is not uncommon for your change to be included in a build that fails due to someone else's changes, or infrastructure issues.

How to do this, and the rest of the post-merge process, is covered in detail here.

If your change does cause a problem, it may be reverted, or you can revert it yourself. This is a normal part of LLVM development. You can fix your changes and open a new PR to merge them again.

If you don't get any reports, no action is required from you. Your changes are working as expected, well done!