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 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits