<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Jun 27, 2017 at 2:09 PM, Friedman, Eli <span dir="ltr"><<a href="mailto:efriedma@codeaurora.org" target="_blank">efriedma@codeaurora.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
  
    
  
  <div text="#000000" bgcolor="#FFFFFF"><span class="">
    <div class="m_-4689985255915253797moz-cite-prefix">On 6/27/2017 1:47 PM, Xinliang David Li
      wrote:<br>
    </div>
    <blockquote type="cite">
      <div dir="ltr"><br>
        <div class="gmail_extra"><br>
          <div class="gmail_quote">On Mon, Jun 26, 2017 at 7:24 PM,
            Friedman, Eli <span dir="ltr"><<a href="mailto:efriedma@codeaurora.org" target="_blank">efriedma@codeaurora.org</a>></span>
            wrote:<br>
            <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
              <div text="#000000" bgcolor="#FFFFFF"><span>
                  <div class="m_-4689985255915253797m_-8178743545387745684moz-cite-prefix">On
                    6/19/2017 7:29 PM, Vedant Kumar wrote:<br>
                  </div>
                  <blockquote type="cite"><br>
                    <div>
                      <blockquote type="cite">
                        <div>
                          <div text="#000000" bgcolor="#FFFFFF">
                            <blockquote type="cite">
                              <div>
                                <div>
                                  <div>We can reduce testing time by
                                    *not* instrumented basic tools like
                                    count, not, FileCheck etc. I filed:
                                    <a href="http://llvm.org/PR33501" target="_blank">llvm.org/PR33501</a>.</div>
                                  <div><br>
                                  </div>
                                  <blockquote type="cite">
                                    <div>
                                      <div>3. The generated profile
                                        information takes up a lot of
                                        space: llc generates a 90MB
                                        profraw file.<br>
                                      </div>
                                    </div>
                                  </blockquote>
                                  <div><br>
                                  </div>
                                  <div>I don't have any ideas about how
                                    to fix this. You can decrease the
                                    space overhead for raw profiles by
                                    altering <span>LLVM_PROFILE_</span><span>MERGE_P</span><span>O<wbr>OL_SIZE
                                      from 4 to a lower value.</span></div>
                                </div>
                              </div>
                            </blockquote>
                            <br>
                            Disk space is cheap, but the I/O takes a
                            long time.  I guess it's specifically bad
                            for LLVM's "make check", maybe not so bad
                            for other cases.<br>
                          </div>
                        </div>
                      </blockquote>
                      <div><br>
                      </div>
                      <div>You can speed up "make check" a bit by using
                        non-instrumented versions of count, not,
                        FileCheck, etc.</div>
                    </div>
                  </blockquote>
                  <br>
                </span> I tried looking into this a bit more.  It looks
                like the profile data file generated by llc contains
                approximately 5MB of counters (__llvm_prf_cnts), 10MB of
                "data" (__llvm_prf_data), and 70MB of __llvm_prf_names. 
                __llvm_prf_data and __llvm_prf_names contain which can
                be read from the original binary, as far as I can tell. 
                The 80MB of data wouldn't be a big deal if it were just
                sitting on disk... but we also erase the whole file and
                rewrite it from scratch after we merge profile counters.<br>
                <br>
              </div>
            </blockquote>
            <div><br>
            </div>
            <div>Can you check if name compression is turned on in your
              build?   </div>
            <div><br>
            </div>
            <div>David</div>
            <br>
          </div>
        </div>
      </div>
    </blockquote>
    <br></span>
    I think it is. At least, I didn't intentionally turn it off, and
    examining the file with objdump I don't see any uncompressed
    strings.  Not sure if there's any easy way to confirm that.</div></blockquote><div><br></div><div><br></div><div>Just a little surprised at the size of __llvm_prf_names section. The llc I built with IR PGO has a __llvm_prf_names section with size  ~1.4MB.    I expect FE instrumentation to produce larger name section size, but not so much bigger.</div><div><br></div><div>David</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div text="#000000" bgcolor="#FFFFFF"><span class=""><br>
    <p>-Eli<br>
    </p>
    <pre class="m_-4689985255915253797moz-signature" cols="72">-- 
Employee of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project</pre>
  </span></div>

</blockquote></div><br></div></div>