[PATCH] D136651: [Clang] Give Clang the ability to use a shared stat cache
Frederic Riss via Phabricator via cfe-commits
cfe-commits at lists.llvm.org
Wed Oct 26 12:32:18 PDT 2022
friss added inline comments.
================
Comment at: llvm/lib/Support/VirtualFileSystem.cpp:3002
+// The format of the stat cache is (pseudo-code):
+// struct stat_cache {
+// char Magic[4]; // "STAT" or "Stat"
----------------
steven_wu wrote:
> Few comments about stats representation.
> 1. Can we version the stat cache file so we can evolve it in the future if needed?
> 2. I wonder if we need to have a more flexible representation for DataType other than `sys::fs::file_status`. Current entry is locked with the endian of the host and can't be used to encode more information than file_status.
> 1. Can we version the stat cache file so we can evolve it in the future if needed?
Yes, we can. I pondered doing it in the original patch but didn't see a reason this would evolve in the future. Of course, I can't predict the future, so maybe a version field is the safe approach.
> 2. I wonder if we need to have a more flexible representation for DataType other than `sys::fs::file_status`. Current entry is locked with the endian of the host and can't be used to encode more information than file_status.
The non-portability of the current cache doesn't bother me as it's meant to mirror filesystem aspects that are local to a machine. Doesn't adding a version number alleviate some of these concerns? If we wanted to add something else in the future, or make it portable, we could just bump that.
I think your comment hints at a higher-level question though. If we were to add something else to the cached data, it wouldn't be a stat cache anymore. Should the feature be a more general "filesystem cache" which starts out with just stat data?
Repository:
rG LLVM Github Monorepo
CHANGES SINCE LAST ACTION
https://reviews.llvm.org/D136651/new/
https://reviews.llvm.org/D136651
More information about the cfe-commits
mailing list