[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