- User Since
- Mar 5 2015, 8:05 AM (351 w, 5 d)
Wed, Nov 24
Tue, Nov 23
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?
- Is there any diagnostic provided if the translator not installed/found?
- 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?
Mon, Nov 8
Ping, @Topotuna do you still plan to commit this?
Just to elaborate on the problem that is being solved. We have ended up with cycling dependencies between LangOptions and TargetInfo i.e. some language options became dependent on the target and vice versa.
FYI the original RFC is https://lists.llvm.org/pipermail/cfe-dev/2021-August/068603.html
Oct 26 2021
Cool. I like the direction... In the end it probably makes sense to separate clang compilation flow into more separate steps. This makes it more suitable to non-LLVM based backends or even MLIR towards Clang Intermediate Language. This looks like a fairly good starting point! Thanks!
This direction of creating a common translator tool makes sense to me! Thanks!
Oct 14 2021
Oct 13 2021
I would like to explain the position of the OpenCL tooling community and the directions we would like to take with SPIR-V support in LLVM. We believe that SPIR-V triple and target should be added explicitly to LLVM/Clang for the following reasons:
Oct 6 2021
Ok, is the idea to deprecate this flag once we switch to llc by default then?
Oct 5 2021
Sep 30 2021
Considering that SPIR-V translation step is also required for other languages would it make sense to add llvm-spirv as a common tool like for example C/C++ linkers and create a bit of common infrastructure? It might be something we can do as a separate step too but it would be good to make sure nothing prevents us from doing this in the future... We should probably also think about the command line interface unification as it probably doesn't make sense for every language to add their own flags for locating SPIR-V translator.
It would be good to get closure on this asap.
Sep 22 2021
Sep 21 2021
Feel free to adjust the naming scheme either in the same commit or separately.
Sep 10 2021
The feature is also C++ for OpenCL specific to let the fast path remain when not utilizing the
address spaces, as this new implementation will be slower than the bitfields that C++ currently
uses, but I hope this can also be optimized in the future if it turns out to be very slow.
Please, address suggested test simplifications in the final commit if applicable.
this is now on the release branch https://github.com/llvm/llvm-project/commit/9723fc15338e83737d0c5f7cbf415e7f1d9d1ec3
Sep 9 2021
- Addressed review comments from @Topotuna
- Reordered items to group features and fixes
Sep 7 2021
Sep 6 2021
Due to the release completion schedule and my planned absences, it is likely that this needs finalizing by the end of the week. Any small changes can still be added later on should you wish to improve something afterwards up until the release branch is frozen. I just want to make sure that we don't miss adding the main content for the release.
Sep 2 2021
Sep 1 2021
Aug 26 2021
This is a very nice clean up!
Aug 25 2021
Do you think we can test this somehow?
Aug 23 2021
Aug 19 2021
I imagine you will be adding some tests that will check the correctness of diagnostic wording in the subsequent commits?
Aug 18 2021
Aug 17 2021
@svenvh I would like to discuss it further with Sven whether it is a good direction or not?
Let's add a reference to RFC in the description: https://lists.llvm.org/pipermail/cfe-dev/2021-August/068593.html
Can you elaborate the overall design flow please? Particularly, it is not clear why we need to duplicate OpenCL types and builtins at source level for SPIR-V... Is there any way to avoid this?