Sccache is a ccache-like tool. It is used as a compiler wrapper and avoids compilation when possible. Sccache has the capability to utilize caching in remote storage environments, including various cloud storage options, or alternatively, in local storage.
Apache License 2.0
5.85k
stars
552
forks
source link
Does sccache support the argument -march=native? #2140
I'm testing cache functionality with the -march=native flag on different computers with different CPU microarchitectures. I determine the architecture using the command:
gcc -march=native -Q --help=target | grep march
1 host - skylake
2 host - haswell
After building a cmake target on one host, all object data was cached. However, when running the build on the second host, I noticed that sccache didn't find suitable artifacts in its cache and began building some object files itself.
Compile requests 66
Compile requests executed 66
Cache hits 14
Cache hits (C/C++) 14
Cache misses 52
Cache misses (C/C++) 52
Upon subsequent runs, sccache detected that it already had the necessary artifacts and reused them.
Compile requests 66
Compile requests executed 66
Cache hits 66
Cache hits (C/C++) 66
Cache misses 0
Cache misses (C/C++) 0
How did sccache understand that these artifacts were not suitable? For the same object file, different hash sums are generated on hosts 1 and 2.
The source code is the same, and the build arguments are identical.
To test, I checked the sha256sum of a sample object file (recompiled on different architectures) on both hosts, and the sha256sum turned out to be the same.
If we assume that sccache itself somewhere inside reveals the optimal arguments for assembly, then why were some of the object files still used from caches?
I'm testing cache functionality with the -march=native flag on different computers with different CPU microarchitectures. I determine the architecture using the command: gcc -march=native -Q --help=target | grep march 1 host - skylake 2 host - haswell
After building a cmake target on one host, all object data was cached. However, when running the build on the second host, I noticed that sccache didn't find suitable artifacts in its cache and began building some object files itself. Compile requests 66 Compile requests executed 66 Cache hits 14 Cache hits (C/C++) 14 Cache misses 52 Cache misses (C/C++) 52
Upon subsequent runs, sccache detected that it already had the necessary artifacts and reused them. Compile requests 66 Compile requests executed 66 Cache hits 66 Cache hits (C/C++) 66 Cache misses 0 Cache misses (C/C++) 0
How did sccache understand that these artifacts were not suitable? For the same object file, different hash sums are generated on hosts 1 and 2. The source code is the same, and the build arguments are identical. To test, I checked the sha256sum of a sample object file (recompiled on different architectures) on both hosts, and the sha256sum turned out to be the same. If we assume that sccache itself somewhere inside reveals the optimal arguments for assembly, then why were some of the object files still used from caches?