================
@@ -2485,10 +2495,10 @@ void LoweringPreparePass::buildCUDAModuleCtor() {
.getName()
.getValue();
- llvm::vfs::FileSystem &vfs =
- astCtx->getSourceManager().getFileManager().getVirtualFileSystem();
+ llvm::vfs::FileSystem &gpuBinaryVFS =
----------------
bcardosolopes wrote:
I went in assuming this was a new dependency and it isn't, it used to come off
`astCtx->getSourceManager().getFileManager().getVirtualFileSystem()`, so
threading it explicitly is honest. Two problems with the shape though.
The fallback is silent. Before this, it was always the invocation's VFS. Now if
nobody calls `setVFS` you quietly read the real filesystem, so a build under
`-ivfsoverlay` or an in-memory VFS picks up the wrong fatbin and says nothing
about it. If the pass needs a VFS, require one and error when it's missing.
Defaulting to the real FS is the kind of thing that gets debugged for a day.
Second, a LoweringPrepare pass holding an `IntrusiveRefCntPtr<vfs::FileSystem>`
and calling `getBufferForFile` is a transform doing I/O. Can the fatbin be
resolved before the pipeline and put in the module, so the pass stays IR to IR?
That also stops you having to thread a filesystem into the `.cir` input path,
which has no invocation VFS to give it.
https://github.com/llvm/llvm-project/pull/219048
_______________________________________________
cfe-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
