Anastasia added a comment. In D109144#3042014 <https://reviews.llvm.org/D109144#3042014>, @bader wrote:
> In D109144#3032865 <https://reviews.llvm.org/D109144#3032865>, @Anastasia > wrote: > >> It would be good to get closure on this asap. >> >> @bader We had related discussions on the other reviews about the approach in >> this patch. If you have any concerns/suggestions can you please notify >> asap... > > Sorry for the delay. I was on vacation last week. I've added my concerns to > the discussion in https://reviews.llvm.org/D108621. In D109144#3042014 <https://reviews.llvm.org/D109144#3042014>, @bader wrote: > In D109144#3032865 <https://reviews.llvm.org/D109144#3032865>, @Anastasia > wrote: > >> It would be good to get closure on this asap. >> >> @bader We had related discussions on the other reviews about the approach in >> this patch. If you have any concerns/suggestions can you please notify >> asap... > > Sorry for the delay. I was on vacation last week. I've added my concerns to > the discussion in https://reviews.llvm.org/D108621. Thanks! Just to summarize here current discussions, the following approaches for the SPIR-V support in Clang are being discussed: 1. Implementing SPIR-V target as SPIR target. @bader do you suggest that we add `spirv` triple to clang and map it into SPIR taget or do you suggest something different? We provide documentation and wider communication in the community that SPIR and SPIR-V are the same target and will be evolved the same way. This would mean that if we do require modifications that are not backward compatible the old ABI might be broken and tools using SPIR would have to adapt. Or if we are to avoid such modifications we would not be able to make a significant improvement to SPIR-V if there are any. 2. Create SPIR-V target as a subclass of SPIR deriving most of the common functionality but leaving the ability to deviate freely. This is essentially what this patch implements. The concern is the code duplication although that should be minimal considering that C++ inheritance and metaprogramming features can be used to effectively share the code. I think to unblock this thread we should request further feedback from the community. - What architectural changes are needed/desired for SPIR-V tooling in LLVM and whether they can be done uniformaly for SPIR and SPIR-V. - What is the envisioned tooling evolution for SPIR and SPIR-V and could we safely consider that they are aligned? Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D109144/new/ https://reviews.llvm.org/D109144 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
