bogner wrote: > 1. If/when we support separate compilation, the user-facing exported > "resource" object will be the resource wrapper, not the handle, so that > indicates to me we should probably have the wrappers being public.
Depending on which aspect of separate compilation you mean, there are a couple of things to note here: 1. For linking DXIL modules (ie, the "lib" profile), these wrappers are irrelevant - we'll create the appropriate globals in lowering 2. For linking LLVM IR modules containing HLSL programs, we probably don't want to make these unequivocally public *or* internal - a resource that's exported should be public, sure, but that IMO should be opt-in, not opt-out. The fact that these are always public today whether or not they need to be causes issues in both the SPIR-V and DirectX backends. In this case, presumably the linking phase would internalize the globals after linking much like LTO does in C/C++ workflows. > 2. It feels wrong to do this in CodeGen. It seems like we should be > identifying an appropriate storage class in Sema such that we assign the > correct linkage automatically. I'll defer to you on this point, but that does sound pretty reasonable. https://github.com/llvm/llvm-project/pull/125718 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
