<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 class="">
    <div class="m_-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><div><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div text="#000000" bgcolor="#FFFFFF">
    Can we do better here?<span class=""><br>
    <br>
    -Eli<br>
    <pre class="m_-8178743545387745684moz-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>