[PATCH] D110618: [HIPSPV][2/4] Add HIPSPV tool chain

[Anastasia Stulova via Phabricator via cfe-commits]

Anastasia added a comment.

In D110618#3152939 <https://reviews.llvm.org/D110618#3152939>, @linjamaki wrote:

> In D110618#3148501 <https://reviews.llvm.org/D110618#3148501>, @Anastasia wrote:
>
>> Could you please clarify the interface to SPIRV-LLVM-Translator tool, specifically:
>>
>> - Does clang lookup the path to the translator or assume any default path?
>
> HIPSPV primarily relies on the system’s PATH for locating the translator.
>
> Additionally, the translator is sought in the same directory where the Clang driver is installed in. This is rather a side-effect than a feature. The directory is added to Clang’s internal search paths for looking up the `clang-offload-bundler` tool required by the HIPSPV tool chain.
>
>> - Is there any diagnostic provided if the translator not installed/found?
>
> Clang displays the following standard error if the translator is not found:
>
>   error: unable to execute command: Executable "llvm-spirv" doesn't exist!
>
>
>
>> - How does clang synchronize with the translator versions i.e. some LLVM IR might not be ingested by certain version of the translator. Would this results in the translator ICE or error in the translator, or is it something that can be diagnosed early by clang or during clang build/installation?
>
> A version mismatch may result in an error in the translator. This is a known issue and a reason we want to switch to the SPIR-V backend when it lands on the LLVM - **the translator is meant to be used temporarily by the HIPSPV**. The synchronization could be improved by having the Clang to seek a SPIR-V Translator binary that is named with the LLVM version it has been built against - e.g. “llvm-spirv-14” for the next LLVM release.
>
> AFAIK, Clang’s infrastructure does not support early diagnosis on external tools. The diagnosis during Clang’s build and installation probably won’t matter much if the Clang is distributed as binary to other systems - the destination system might not have the required translator version.

Alternatively, we could see if translator could emit a diagnostic by looking at the clang version emitted in metadata... I presume this might not be too hard to implement...


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D110618/new/

https://reviews.llvm.org/D110618