[SYCL RTC] Introduce --persistent-auto-pch support
#20374
+673
−88
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Built on top of `--auto-pch` (in-memory) introduced in intel#20226. The most significant technical decision was how to implement the filesystem cache. I've looked into the following options: * `sycl/source/detail/persistent_device_code_cache.hpp` Also, see `sycl/doc/design/KernelProgramCache.md` Seems to be tailored for the very specific usage scenarios, would be very resource consuming to split into a generic data structure that would then be used for two different use cases. This cache is disabled by default and I'm not sure how well-tested it is. Also, using plain ".lock" files for "advisory locking" instead of the native filesystem mechanisms (e.g., locking APIs in `fcntl`/`flock`/`CreateFile`/`LockFileEx`) made me question if it's worth generalizing and how much work would be necessary there. * `llvm/include/llvm/Support/Caching.hpp` Originally implemented as part of ThinLTO implementation, moved into `LLVMSupport` later with the following commit message: > We would like to move ThinLTO’s battle-tested file caching > mechanism to the LLVM Support library so that we can use it > elsewhere in LLVM. API is rather unexpected, so my research hasn't stopped here. * `lldb/include/lldb/Core/DataFileCache.h` Uses `LLVMSupport`'s caching from the previous bullet under the hood, but provides an easier to grasp API. If we were developing upstream I think uplifting that abstraction into `LLVMSupport` library and then using in both `lldb` and `libsycl` would probably be the choice I'd vote for. However, doing that downstream was too much efforts so I ultimately decided not to go with this approach. That cache also has a `std::mutex` on the "hot" `DataFileCache::GetCachedData` path, I presume to avoid creating the same entry from multiple threads. In the end, I've chosen to use `LLVMSupport`'s quirky (or maybe I just hasn't grown enough to appreciate it) caching API directly and that's what is done in this PR. Unlike `lldb`'s cache, I decided to trade possible duplicate work of building the preamble on a cache miss from concurrent threads in favor of no inter-thread synchronization (not profiled/measured though) on the cache hit path and implementation simplicity.
aelovikov-intel
requested review from
a team and
cperkinsintel
as code owners
aelovikov-intel
had a problem deploying
to
WindowsCILock
GitHub Actions
Failure
aelovikov-intel
had a problem deploying
to
WindowsCILock
GitHub Actions
Failure
aelovikov-intel
had a problem deploying
to
WindowsCILock
GitHub Actions
Failure
aelovikov-intel
temporarily deployed
to
WindowsCILock
GitHub Actions
Inactive
aelovikov-intel
had a problem deploying
to
WindowsCILock
GitHub Actions
Failure
aelovikov-intel
had a problem deploying
to
WindowsCILock
GitHub Actions
Failure
aelovikov-intel
temporarily deployed
to
WindowsCILock
GitHub Actions
Inactive
aelovikov-intel
had a problem deploying
to
WindowsCILock
GitHub Actions
Failure
aelovikov-intel
temporarily deployed
to
WindowsCILock
GitHub Actions
Inactive
persistent_auto_pch_stress_deletion.cpp triggers failed `commit` better
aelovikov-intel
temporarily deployed
to
WindowsCILock
GitHub Actions
Inactive
aelovikov-intel
had a problem deploying
to
WindowsCILock
GitHub Actions
Failure
aelovikov-intel
had a problem deploying
to
WindowsCILock
GitHub Actions
Failure
gmlueck
reviewed
Oct 16, 2025
sycl/doc/extensions/experimental/sycl_ext_oneapi_kernel_compiler.asciidoc
Show resolved
Hide resolved
aelovikov-intel
temporarily deployed
to
WindowsCILock
GitHub Actions
Inactive
aelovikov-intel
had a problem deploying
to
WindowsCILock
GitHub Actions
Failure
aelovikov-intel
had a problem deploying
to
WindowsCILock
GitHub Actions
Failure
aelovikov-intel
temporarily deployed
to
WindowsCILock
GitHub Actions
Inactive
aelovikov-intel
had a problem deploying
to
WindowsCILock
GitHub Actions
Failure
aelovikov-intel
had a problem deploying
to
WindowsCILock
GitHub Actions
Failure
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Built on top of
--auto-pch(in-memory) introduced in #20226.The most significant technical decision was how to implement the filesystem cache. I've looked into the following options:
sycl/source/detail/persistent_device_code_cache.hppAlso, seesycl/doc/design/KernelProgramCache.mdSeems to be tailored for the very specific usage scenarios, would be very resource consuming to split into a generic data structure that would then be used for two different use cases.This cache is disabled by default and I'm not sure how well-tested it is. Also, using plain ".lock" files for "advisory locking" instead of the native filesystem mechanisms (e.g., locking APIs in
fcntl/flock/CreateFile/LockFileEx) made me question if it's worth generalizing and how much work would be necessary there.llvm/include/llvm/Support/Caching.hppOriginally implemented as part of ThinLTO implementation, moved intoLLVMSupportlater with the following commit message:API is rather unexpected, so my research hasn't stopped here.
lldb/include/lldb/Core/DataFileCache.hUsesLLVMSupport's caching from the previous bullet under the hood, but provides an easier to grasp API. If we were developing upstream I think uplifting that abstraction intoLLVMSupportlibrary and then using in bothlldbandlibsyclwould probably be the choice I'd vote for. However, doing that downstream was too much efforts so I ultimately decided not to go with this approach.That cache also has a
std::mutexon the "hot"DataFileCache::GetCachedDatapath, I presume to avoid creating the same entry from multiple threads.In the end, I've chosen to use
LLVMSupport's quirky (or maybe I just hasn't grown enough to appreciate it) caching API directly and that's what is done in this PR. Unlikelldb's cache, I decided to trade possible duplicate work of building the preamble on a cache miss from concurrent threads in favor of no inter-thread synchronization (not profiled/measured though) on the cache hit path and implementation simplicity.