beanz added a comment. In D135110#3832728 <https://reviews.llvm.org/D135110#3832728>, @tschuett wrote:
> The OpenMP frontend is mainly an IRBuilder. It is a different layering than > for HLSL. Are there plans for an HLSL(IR)Builder? HLSL and OpenMP are different in a lot of ways. HLSL's code generation is fairly consistent with C/C++. There will be some areas where we have special IR generation mechanics (like around copy-in/copy-out function parameters), which I expect we'll create some sort of reusable API for. I'm unsure if we have enough unique cases to make a full builder worth it. Similar to OpenCL we also have a lot of metadata that needs to get passed from the frontend to the backend. That's really where this patch is starting. Having shared utilities for reading and writing metadata. ================ Comment at: llvm/include/llvm/Frontend/HLSL/HLSLResource.h:35 + GlobalVariable *getGlobalVariable(); + StringRef getSourceType(); + Constant *getID(); ---------------- python3kgae wrote: > Could we save things like shape and component type instead of a StringRef > which needs to be parsed later? This change is an NFC refactoring to move code around and start sharing between the front-end and backend. We have a separate issue tracking extending the frontend attribute support to capture more metadata (https://github.com/llvm/llvm-project/issues/57991). That will be a separate change. Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D135110/new/ https://reviews.llvm.org/D135110 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
