https://github.com/MrSidims commented:
Thanks, it should make LLVM IR after optimizations more translatable in SPIR-V! Few questions though: 1. Usually (or at least AFAIK) optimization passes won't consider datalayout automatically, as LLVM defines datalayout not as a contract set by the frontend, but a contact, that the code generator expects. Do you plan to go over LLVM passes adding this check? 2. Some existing and future extensions might allow extra bit widths for integers. For example here is [SPV_INTEL_arbitrary_precision_integers](https://github.com/KhronosGroup/SPIRV-Registry/blob/main/extensions/INTEL/SPV_INTEL_arbitrary_precision_integers.asciidoc) extension that allows any bit widths for integers (it's actually a bad example as it's developed only for _BitInt C23 extension and FPGA hardware, so datalayout wouldn't have an impact on it) or one of the internally discussed within Khronos extensions for ML (which might be impacted by this change). Can we envision, how can we change datalayout information depending on the enabled extensions (or you don't think it's a big problem?) https://github.com/llvm/llvm-project/pull/110695 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
