> The .gcda files themselves aren't cached, their contents are used to > calculate the hash for a -fprofile-use run. So if the .o file doesn't > exist, and you have the same .gcda file, you get a cache hit.
Ah, I see. What if the .o file does exist? Why should that matter, if gcc is going to overwrite it anyway? You mentioned earlier that a simple program without branches or loops didn't generate the same .gcda files when the program was run twice. Would you mind including that code? I wrote a pretty simple testcase and observed the opposite result. Maybe it's different in different versions of gcc or something. -Justin On Mon, Aug 8, 2011 at 10:27 AM, Chris AtLee <ch...@atlee.ca> wrote: > On Mon, Aug 8, 2011 at 10:06 AM, Justin Lebar <justin.le...@gmail.com> wrote: >> On Mon, Aug 8, 2011 at 9:58 AM, Chris AtLee <ch...@atlee.ca> wrote: >>> Any thoughts on if caching the .gcda files is useful? Maybe have >>> another environment variable that switches it on? >> >> What do you mean? These files aren't generated until the program is >> run, right? So I guess what you're suggesting is that on the >> -fprofile-use pass, we'd remember the gcda file that was there. Then >> on a later -fprofile-generate pass, if we have a cache hit, we'd >> restore both the object and the gcda file that object eventually >> created when it ran. > > The .gcda files themselves aren't cached, their contents are used to > calculate the hash for a -fprofile-use run. So if the .o file doesn't > exist, and you have the same .gcda file, you get a cache hit. > _______________________________________________ ccache mailing list ccache@lists.samba.org https://lists.samba.org/mailman/listinfo/ccache
