Does sccache support the argument -march=native? #2141
Replies: 2 comments 1 reply
-
Please don't use issues to ask questions. ;) See the block here: Line 700 in a859c3b |
Beta Was this translation helpful? Give feedback.
-
After conducting more detailed testing of sccache across various CPU architectures, I have concluded that sccache cannot correctly handle compilation arguments such as -march=native -O3. During the project compilation, my object files consistently yield the same hash sum, even when different CPU instructions were utilized for optimization. |
Beta Was this translation helpful? Give feedback.
-
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?
Beta Was this translation helpful? Give feedback.
All reactions