[ccache] Support for -fprofile-generate, -fprofile-use, -fprofile-arcs
Justin Lebar
justin.lebar at gmail.com
Mon Aug 8 14:24:38 MDT 2011
> 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 <chris at atlee.ca> wrote:
> On Mon, Aug 8, 2011 at 10:06 AM, Justin Lebar <justin.lebar at gmail.com> wrote:
>> On Mon, Aug 8, 2011 at 9:58 AM, Chris AtLee <chris at 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.
>
More information about the ccache
mailing list