<div dir="ltr">My assumption is there that there can be value profiles when libc is not linked in.<div>I have a test case to show the problem: this is just a a normal program with indirect calls but  with _llvm_profile_runtime set to 0. The program write the profile by itself.</div><div><br></div><div>  I'm not sure if the use case where libc is not linked in.</div></div><br><div class="gmail_quote"><div dir="ltr">On Mon, Mar 26, 2018 at 11:30 AM Xinliang David Li <<a href="mailto:davidxl@google.com">davidxl@google.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><br><br><br><div class="gmail_quote"><div dir="ltr">On Mon, Mar 26, 2018 at 11:24 AM Rong Xu via Phabricator <<a href="mailto:reviews@reviews.llvm.org" target="_blank">reviews@reviews.llvm.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">xur added inline comments.<br>
<br>
<br>
================<br>
Comment at: lib/profile/InstrProfilingFile.c:230<br>
+  // (which can leave garbage at the end of profile file).<br>
+  if (!VPMergeHook)<br>
+    truncate(ProfileFileName, 0);<br>
----------------<br>
davidxl wrote:<br>
> xur wrote:<br>
> > davidxl wrote:<br>
> > > xur wrote:<br>
> > > > davidxl wrote:<br>
> > > > > non value profiling data has fixed size, so why is this needed?<br>
> > > > Because there are still value counts in both in-memory and in-disk profiles.<br>
> > > ><br>
> > > > Using the test in the patch as the example (running on my machine).<br>
> > > > assuming the binary is named as 'gen' and VPMergeHook null.<br>
> > > ><br>
> > > > if we don't do online merge,<br>
> > > > "gen" will generate a profile of size 320 bytes.<br>
> > > > "gen 1" will generate a profile with size of 352 bytes<br>
> > > ><br>
> > > > If we run "gen 1 && gen", the result binary is still 352 bytes.<br>
> > > > But the effective size is 320 bytes. The tail 32 bytes are trash.<br>
> > > ><br>
> > > ><br>
> > > Without VpMergeHook, we should assert that there is no value profile data -- it should not be dumped in the first place.<br>
> > current behavior is to write out the in-memory value profile data and discard the value profile data in the file. if there is not value profile from the file, the result is still correct.<br>
> ><br>
> > I'm not familiar with the use cast the not having libc (where VPMergeHook will be nullptr). Is it not suppose to have any value profile?<br>
> ><br>
> > I can assert VPMergeHook==nullptr and in-memory valuesites are not empty. That will be easy. Is this what you suggested?<br>
> In lprofGetVPDataReader method, returns null if VPMergeHook is null.<br>
This will generate incorrect profile: the valuesite in the data section says there are valuesites but VP count is empty.<br>
<br></blockquote><div><br></div><div>We should assert that when VPMergeHook is null, the data section has no value sites.  Do you see a possible case this does not hold?</div><div><br></div><div>David</div><div><br></div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
if we do this, the behavior would be: llvm-profdata show or merge command will stop silently at the first function that has the value-site instrumentation. The rest profile will be discarded.<br>
<br>
Note, of course, this only applies to  VPMergeHook==nullptr case.<br>
<br>
<br>
<a href="https://reviews.llvm.org/D44847" rel="noreferrer" target="_blank">https://reviews.llvm.org/D44847</a><br>
<br>
<br>
<br>
</blockquote></div></div>
</blockquote></div>