Enable ccache for CI builds

[TerrorJack]

This PR enables ccache for LLVM in CI, and shall speed up building processes for subsequent PRs in this repo.

[sbc100]

Great! Did you measure the speedup? Presumably subsequent builds with the same llvm version should have a very high hit rate?

[sbc100]

Maybe put this add the of the command line (line 77)?

[TerrorJack]

Do you mean the bottom of the command line? Sure, will do after the current pipeline finishes.

[sbc100]

What is run_id? Wouldn't we want the cache to be shared between different runs of the workflow?

[TerrorJack]

Hi, see https://github.com/actions/cache/blob/main/tips-and-workarounds.md#update-a-cache for details. Adding a run_id suffix ensures that when we bump LLVM revision in the future, the cache can get updated accordingly; and the fallback key here ensures the workflow can receive cache from previous workflows.

[sbc100]

Can you explain a little more.. how does this ensure that "when we bump LLVM revision in the future, the cache can get updated accordingly"? Where is the llvm revision encoded here?

From that link the "Please note that this will create a new cache on every run and hence will consume the cache quota" is a little worrying.. do we really need to store a separate copy of the ccache data for each run?

Sorry, this is my first time the cache action in github so I'm probably misunderstanding.

This change lgtm assuming it actually speeds up builds..

[TerrorJack]

Ah never mind! I'll try to explain it as a bullet-point list, and do let me know if further clarification is needed:

• Each GitHub cache is an immutable blob indexed by a key
• The actions/cache step will attempt to fetch the blob via that key, if not present, the cache is created and uploaded (first run)
• If key doesn't have a unique suffix, subsequent runs have cache hit, but doesn't update the cache, because it's immutable by design
• So in the future when we bump LLVM, we end up with stale cache in each run
• So we append run_id to the cache key. Now, we ensure the cache key is always unique, and the cache is always created and uploaded, so no stale cache problem
• Additionally, we have restore-keys which is just the key without the unique suffix. actions/cache will 100% miss the unique key, but then it'll look up restore-keys and it'll see some previously created caches with that prefix, and the most recent one is restored
• The 0- prefix on all cache keys is a precautionary prefix; in the future if the cache become corrupted and break builds, and we don't want to eliminate caching logic at all, simply bump this epoch number will allow ignoring all previous caches altogether
• Once the cache quota begins to be reached, the older ones get garbage collected
• No need to encode LLVM revision anywhere

[sbc100]

I see. That makes sense. Might be worth a comment regarding how the epoch thing works. Something like "bump this to to avoid using cached object files from previous builds, for example, if we update host version of clang"

[TerrorJack]

Will add a comment. Though ccache is smart enough to notice host compiler updates, so epoch bumps is very unlikely going to be useful anyway.

[sbc100]

Can you explain a little more.. how does this ensure that "when we bump LLVM revision in the future, the cache can get updated accordingly"? Where is the llvm revision encoded here?

From that link the "Please note that this will create a new cache on every run and hence will consume the cache quota" is a little worrying.. do we really need to store a separate copy of the ccache data for each run?

Sorry, this is my first time the cache action in github so I'm probably misunderstanding.

This change lgtm assuming it actually speeds up builds..

[TerrorJack]

@sbc100 Ready for merge, all jobs are green and confirmed to be cached now. The macos and docker jobs just uploaded their first cache so there's no comparison; meanwhile, for other cached jobs, the speedup is very promising (comparing with latest master pipeline):

Job	Before	After
ubuntu-latest	1h 46m 10s	11m 11s
windows x64	2h 28m 43s	25m 4s
windows x86	2h 4m 19s	24m 35s