<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Oct 26, 2017 at 1:31 AM, Roger Pau Monné <span dir="ltr"><<a href="mailto:roger.pau@citrix.com" target="_blank">roger.pau@citrix.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On Wed, Oct 25, 2017 at 09:13:54AM -0700, Xinliang David Li wrote:<br>
> On Wed, Oct 25, 2017 at 12:26 AM, Roger Pau Monné via llvm-dev <<br>
> <a href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a>> wrote:<br>
><br>
> > Hello,<br>
> ><br>
> > I've been working on implementing some basic functionality in order to<br>
> > use the llvm profiling functionality inside of a kernel (the Xen<br>
> > hypervisor). The only functionality I'm interested in is being able to<br>
> > reset the counters, get the size of the data, and dump the data into a<br>
> > memory buffer.<br>
> ><br>
> > I have to admit I haven't been able to find a lot of documentation<br>
> > about how this data is stored inside of the different sections, but<br>
> > with the code in compiler_rt/libs/profile I've been able to craft<br>
> > something that seems to do something sensible.<br>
> ><br>
> > I have however a couple of questions:<br>
> ><br>
> > - The "Values" field in __llvm_profile_data always seems to be NULL.<br>
> > Is this expected? What/why could cause this?<br>
> ><br>
><br>
> This is for value profiling. For now there are only two kinds: indirect<br>
> call targets and memcpy/memset size. If the function body does not have any<br>
> value sites, the field will be null.<br>
<br>
</span>You will have to bear with me because my knowledge of compiler<br>
internals is very limited. What is exactly a "value site"?<br>
<br></blockquote><div><br></div><div>It refers to a location in a function where the compiler inserts the value profiling hook.</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Can you give me some code examples that trigger this in C?<br></blockquote><div><br></div><div><br></div><div>typedef void (*FP)(void);</div><div><br></div><div>void test (FP fp) {</div><div><br></div><div> fp(); /* a value site */</div><div>}</div><div><br></div><div><br></div><div>There are two ways to turn on value profiling:</div><div><br></div><div>1) using instrumentation for PGO (we call it IR-PGO):</div><div><br></div><div> -fprofile-generate </div><div><br></div><div><br></div><div>2) using Front-end based instrumentation which is used for coverage testing:</div><div><br></div><div> -fprofile-instr-generate -mllvm -enable-value-profiling=true</div><div><br></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">
<span class=""><br>
> ><br>
> > - Since what I'm coding is a decoupled replacement for the profiling<br>
> > runtime inside of compiler_rt, is there anyway that at compile or<br>
> > run time I can fetch the version of the profiling data?<br>
> ><br>
><br>
> At compile time, it is the macro: INST_PROF_RAW_VERSION. At runtime, it is<br>
> the second field of the raw profile header.<br>
<br>
</span>I'm not able to use INST_PROF_RAW_VERSION at compile time. Are you<br>
sure this is exported? If I do:<br>
<br>
cc -fprofile-instr-generate -fcoverage-mapping -dM -E - < /dev/null<br>
<br></blockquote><div><br></div><div>Ok. The macro is defined for building the compiler itself, but not passed down to the user program when compiling it. </div><div><br></div><div>If you use IR-PGO (turned on with -fprofile-generate), the information is stored in a symbol in rodata: __llvm_profile_raw_version -- the least significant 32bits has the value of the raw version. Unfortunately, the front-end based instrumentation currently does not emit such a symbol.</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I don't see INST_PROF_RAW_VERSION neither any similar defines.<br>
<span class=""><br>
> I'm mostly worried that at some point llvm will bump the version<br>
> > and change the layout, and then I will have to update my runtime<br>
> > accordingly, but without llvm reporting the version used by the<br>
> > compiler it's going to be very hard to keep backwards<br>
> > compatibility or to detect version bumps.<br>
> ><br>
> ><br>
> yes, the raw profile format can change anytime. We only try to keep<br>
> backward compatibility for indexed format.<br>
><br>
> At runtime with in-process profile merging, if the source raw profile<br>
> data's format version is different from the current runtime version, an<br>
> error will be emitted.<br>
<br>
</span>Keep in mind this is a kernel, so the source is compiled with<br>
"-fprofile-instr-generate -fcoverage-mapping", but the profiling<br>
runtime in compiler_rt is not linked against the kernel.<br>
<br>
I would like to have a reliable way that I could use to detect version<br>
bumps in the internal coverage data, so that I can implement the<br>
required changes in my in-kernel coverage code.<br>
<br>
I have a series ready for Xen in order to implement this, I will send<br>
the patch with the in-kernel profiling implementation to this list for<br>
review.<br></blockquote><div><br></div><div><br></div><div>The right way for this is to define __llvm_profile_raw_version variable with FE instrumentation as is done by IR-PGO. I have cc'ed Vedant who may help with this.</div><div><br></div><div>thanks,</div><div><br></div><div>David</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Thanks, Roger.<br>
</blockquote></div><br></div></div>