[llvm] [SPIRV] Emit LinkageType for function with hidden visibility (PR #164374)

[Steven Perron via llvm-commits]

Juan Manuel Martinez =?utf-8?q?Caamaño?= <juamarti at amd.com>
Message-ID:
In-Reply-To: <llvm.org/llvm/llvm-project/pull/164374 at github.com>


s-perron wrote:

This might not work well for HLSL as is. See https://github.com/llvm/wg-hlsl/blob/main/proposals/0026-symbol-visibility.md.

> "hidden" visibility is different from "internal/private" linkage types. A global variable or function with hidden public linkage should still be visible to other compilation units in the same "shared object".

It is also different from something with default visibility. Something will be "wrong" because, as you noted, SPIR-V cannot make that distinction.

Some of the difficulties with this is that SPIR-V does not have a concept of a shared object. We have modules. Spirv-link can link modules. For HLSL, we took the view that a module is a shared object, and you could link the shared object. This is because there is a long term plan to have linking done at the llvm-ir level. So the individual llvm-ir files are a translation unit, but they are "linked" before entering the BE to be a shared library. We could add an "HLSL linking pass" before reaching the backend that will change the linkage of the symbols, however, to be accepted we might need to do a full linking tool.

Can you write up a design doc on how you want the linkages to work for OpenCL? Also, do you know which language constructs result in hidden visibility? We should be able to find a solution that works for everyone.

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