via llvm-dev
2017-Jun-27 21:41 UTC
[llvm-dev] My experience using -DLLVM_BUILD_INSTRUMENTED_COVERAGE to generate coverage
With llc, the size of the names section can vary widely depending on the value of -DLLVM_TARGETS_TO_BUILD. Enabling coverage shouldn't increase the name section size much. I only see one place where this happens, and it's relatively cold: http://lab.llvm.org:8080/coverage/coverage-reports/llvm/coverage/Users/buildslave/jenkins/sharedspace/clang-stage2-coverage-R at 2/llvm/lib/Transforms/Instrumentation/InstrProfiling.cpp.html#L512 <http://lab.llvm.org:8080/coverage/coverage-reports/llvm/coverage/Users/buildslave/jenkins/sharedspace/clang-stage2-coverage-R at 2/llvm/lib/Transforms/Instrumentation/InstrProfiling.cpp.html#L512>> On Jun 27, 2017, at 2:40 PM, Friedman, Eli <efriedma at codeaurora.org> wrote: > > I get a bunch of unreadable binary. Output piped to "less": > > String dump of section '__llvm_prf_names': > [ 2] #<CA>^Ex<DA><D4>is<E3>(^Z<EF>^O<DD>^P<A9><D5><F7><9B><CB><FB><A8>d<97>^U<96>O<9F><89><FB><85>AQ<B4>M<B5><B6>&)Wy~<FD>C^B\<B0>/$<A5><EA>s<E3><CE>L<97>E$^R<89>Dn<C8>L<84><FF> > <EF><C7>h<B7><FB><DC>ߊ,=<BC><BF>$ow~<B0>\<C4><FF>_X<FE><E0><C7><D1>&<C9>c<F4><E7>^_<AB><B0><F9>,`<BE>H^Oi1G<BF>{<E3><D7>({O<8A><E7>S<91>^^^O<B9>7<BB><CD><F7><F3>C^d<E7>}r("<F8>c^P P<83> > <D0><F3>`T^Z<ED><D2><FF>M<B2><F9>k^X^D/<8B><D5>8<A4><E1>N><A3><DD>9<C9><E7><DF><F1><F7>c^B38<9C><F7>^<BF><C2>ߕ^_<D6><F0>_<F2><BB>]<94><E7><C1><FD><E9><95>^A3<<9E>^\<B0>{\^O0<CC><C9>)<CA>r<84><D9>j^H<B3><DC><F9><F3><EF><B7><FE> <8C><E1>'L^Q<C9>"<F0><A7>"><E8><FF><DD>^^V^R<A4><D6><FC>d<EB>j*oHO<D5>^F<C2>p<D0>^U<82><EF>^Y!<90><9D>O5;:^TgL<F9>^Y<D3>z<D5>#=<81><E1><C3>6<C4>^\u%<85>7<EE>^Jaf^D0C<8B><8C>r^D^E<9D><B5>^W^L<A3>dx<FA><A3>1<FE><88>l^OO<AB>^Z<80>^\~^I<EE><DE>^O>]V~c<C9>^D<B7><88>[4|0^R<89><B5>ʳ<96><D7>Ӽ<E7><F9>^D<EB>^<BF><A5><9B>Mr^Ht<CC>A^PP<EF> > <8D>n<BA><89>q<91><DE>This looks compressed to me. vedant> > -Eli > > On 6/27/2017 2:32 PM, Xinliang David Li wrote: >> I had an old build of llc with FE instrumentation, the name section size is about 5MB. Using coverage is likely to cause the name section to be larger as there are more references to dead/unused function names. >> >> What do you see when >> >> readelf --string-dump=__llvm_prf_names llc >> >> David >> >> On Tue, Jun 27, 2017 at 2:23 PM, Xinliang David Li <davidxl at google.com <mailto:davidxl at google.com>> wrote: >> >> >> On Tue, Jun 27, 2017 at 2:09 PM, Friedman, Eli <efriedma at codeaurora.org <mailto:efriedma at codeaurora.org>> wrote: >> On 6/27/2017 1:47 PM, Xinliang David Li wrote: >>> >>> >>> On Mon, Jun 26, 2017 at 7:24 PM, Friedman, Eli <efriedma at codeaurora.org <mailto:efriedma at codeaurora.org>> wrote: >>> On 6/19/2017 7:29 PM, Vedant Kumar wrote: >>>> >>>>>> We can reduce testing time by *not* instrumented basic tools like count, not, FileCheck etc. I filed: llvm.org/PR33501 <http://llvm.org/PR33501>. >>>>>> >>>>>>> 3. The generated profile information takes up a lot of space: llc generates a 90MB profraw file. >>>>>> >>>>>> I don't have any ideas about how to fix this. You can decrease the space overhead for raw profiles by altering LLVM_PROFILE_MERGE_POOL_SIZE from 4 to a lower value. >>>>> >>>>> 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. >>>> >>>> You can speed up "make check" a bit by using non-instrumented versions of count, not, FileCheck, etc. >>> >>> 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. >>> >>> >>> Can you check if name compression is turned on in your build? >>> >>> David >>> >> >> 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. >> >> >> 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. >> >> David >> >> -Eli >> -- >> Employee of Qualcomm Innovation Center, Inc. >> Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project >> >> > > -- > Employee of Qualcomm Innovation Center, Inc. > Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20170627/5efba24c/attachment.html>
Xinliang David Li via llvm-dev
2017-Jun-27 21:48 UTC
[llvm-dev] My experience using -DLLVM_BUILD_INSTRUMENTED_COVERAGE to generate coverage
On Tue, Jun 27, 2017 at 2:41 PM, <vsk at apple.com> wrote:> With llc, the size of the names section can vary widely depending on the > value of -DLLVM_TARGETS_TO_BUILD. > >Sure.> Enabling coverage shouldn't increase the name section size much. I only > see one place where this happens, and it's relatively cold: > http://lab.llvm.org:8080/coverage/coverage-reports/llvm/coverage/Users/ > buildslave/jenkins/sharedspace/clang-stage2-coverage-R at 2/llvm/lib/ > Transforms/Instrumentation/InstrProfiling.cpp.html#L512 > >What is the data set used to create the coverage data there? Looks like the lower Coverage function is called 6 times (aka only 6 modules have coverage data) and on average, each coverage data only references ~2 names. This does not seem typical.> > On Jun 27, 2017, at 2:40 PM, Friedman, Eli <efriedma at codeaurora.org> > wrote: > > I get a bunch of unreadable binary. Output piped to "less": > > String dump of section '__llvm_prf_names': > [ 2] #<CA>^Ex<DA><D4>is<E3>(^Z<EF>^O<DD>^P<A9><D5><F7><9B><CB>< > FB><A8>d<97>^U<96>O<9F><89><FB><85>AQ<B4>M<B5><B6>&)Wy~< > FD>C^B\<B0>/$<A5><EA>s<E3><CE>L<97>E$^R<89>Dn<C8>L<84><FF> > <EF><C7>h<B7><FB><DC>ߊ,=<BC><BF>$ow~<B0>\<C4><FF>_X<FE><E0> > <C7><D1>&<C9>c<F4><E7>^_<AB><B0><F9>,`<BE>H^Oi1G<BF>{<E3>< > D7>({O<8A><E7>S<91>^^^O<B9>7<BB><CD><F7><F3>C^d<E7>}r("<F8>c^P P<83> > <D0><F3>`T^Z<ED><D2><FF>M<B2><F9>k^X^D/<8B><D5>8<A4><E1>N>< > A3><DD>9<C9><E7><DF><F1><F7>c^B38<9C><F7>^<BF><C2>ߕ^_<D6>< > F0>_<F2><BB>]<94><E7><C1><FD><E9><95>^A3<<9E>^\<B0>{\^O0<CC> > <C9>)<CA>r<84><D9>j^H<B3><DC><F9><F3><EF><B7><FE> > <8C><E1>'L^Q<C9>"<F0><A7>"><E8><FF><DD>^^V^R<A4><D6><FC>d< > EB>j*oHO<D5>^F<C2>p<D0>^U<82><EF>^Y!<90><9D>O5;:^TgL<F9>^Y< > D3>z<D5>#=<81><E1><C3>6<C4>^\u%<85>7<EE>^Jaf^D0C<8B><8C>r^ > D^E<9D><B5>^W^L<A3>dx<FA><A3>1<FE><88>l^OO<AB>^Z<80>^\~^I< > EE><DE>^O>]V~c<C9>^D<B7><88>[4|0^R<89><B5>ʳ<96><D7>Ӽ<E7>< > F9>^D<EB>^<BF><A5><9B>Mr^Ht<CC>A^PP<EF> > <8D>n<BA><89>q<91><DE> > > > This looks compressed to me. > >Yes. David> vedant > > > > -Eli > > On 6/27/2017 2:32 PM, Xinliang David Li wrote: > > I had an old build of llc with FE instrumentation, the name section size > is about 5MB. Using coverage is likely to cause the name section to be > larger as there are more references to dead/unused function names. > > What do you see when > > readelf --string-dump=__llvm_prf_names llc > > David > > On Tue, Jun 27, 2017 at 2:23 PM, Xinliang David Li <davidxl at google.com> > wrote: > >> >> >> On Tue, Jun 27, 2017 at 2:09 PM, Friedman, Eli <efriedma at codeaurora.org> >> wrote: >> >>> On 6/27/2017 1:47 PM, Xinliang David Li wrote: >>> >>> >>> >>> On Mon, Jun 26, 2017 at 7:24 PM, Friedman, Eli <efriedma at codeaurora.org> >>> wrote: >>> >>>> On 6/19/2017 7:29 PM, Vedant Kumar wrote: >>>> >>>> >>>> We can reduce testing time by *not* instrumented basic tools like >>>> count, not, FileCheck etc. I filed: llvm.org/PR33501. >>>> >>>> 3. The generated profile information takes up a lot of space: llc >>>> generates a 90MB profraw file. >>>> >>>> >>>> I don't have any ideas about how to fix this. You can decrease the >>>> space overhead for raw profiles by altering LLVM_PROFILE_MERGE_POOL_SIZE >>>> from 4 to a lower value. >>>> >>>> >>>> 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. >>>> >>>> >>>> You can speed up "make check" a bit by using non-instrumented versions >>>> of count, not, FileCheck, etc. >>>> >>>> >>>> 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. >>>> >>>> >>> Can you check if name compression is turned on in your build? >>> >>> David >>> >>> >>> 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. >>> >> >> >> 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. >> >> David >> >>> >>> -Eli >>> >>> -- >>> Employee of Qualcomm Innovation Center, Inc. >>> Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project >>> >>> >> > > -- > Employee of Qualcomm Innovation Center, Inc. > Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project > > >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20170627/f4c77191/attachment.html>
via llvm-dev
2017-Jun-27 21:54 UTC
[llvm-dev] My experience using -DLLVM_BUILD_INSTRUMENTED_COVERAGE to generate coverage
> On Jun 27, 2017, at 2:48 PM, Xinliang David Li <davidxl at google.com> wrote: > > > > On Tue, Jun 27, 2017 at 2:41 PM, <vsk at apple.com <mailto:vsk at apple.com>> wrote: > With llc, the size of the names section can vary widely depending on the value of -DLLVM_TARGETS_TO_BUILD. > > > Sure. > > Enabling coverage shouldn't increase the name section size much. I only see one place where this happens, and it's relatively cold: > http://lab.llvm.org:8080/coverage/coverage-reports/llvm/coverage/Users/buildslave/jenkins/sharedspace/clang-stage2-coverage-R at 2/llvm/lib/Transforms/Instrumentation/InstrProfiling.cpp.html#L512 <http://lab.llvm.org:8080/coverage/coverage-reports/llvm/coverage/Users/buildslave/jenkins/sharedspace/clang-stage2-coverage-R at 2/llvm/lib/Transforms/Instrumentation/InstrProfiling.cpp.html#L512> > > > > What is the data set used to create the coverage data there? Looks like the lower Coverage function is called 6 times (aka only 6 modules have coverage data) and on average, each coverage data only references ~2 names. This does not seem typical.It's check-llvm, check-clang, plus the test suite. lowerCoverageData doesn't get called unless we need to emit empty counter mappings, for things like functions with empty bodies. vedant> > > >> On Jun 27, 2017, at 2:40 PM, Friedman, Eli <efriedma at codeaurora.org <mailto:efriedma at codeaurora.org>> wrote: >> >> I get a bunch of unreadable binary. Output piped to "less": >> >> String dump of section '__llvm_prf_names': >> [ 2] #<CA>^Ex<DA><D4>is<E3>(^Z<EF>^O<DD>^P<A9><D5><F7><9B><CB><FB><A8>d<97>^U<96>O<9F><89><FB><85>AQ<B4>M<B5><B6>&)Wy~<FD>C^B\<B0>/$<A5><EA>s<E3><CE>L<97>E$^R<89>Dn<C8>L<84><FF> >> <EF><C7>h<B7><FB><DC>ߊ,=<BC><BF>$ow~<B0>\<C4><FF>_X<FE><E0><C7><D1>&<C9>c<F4><E7>^_<AB><B0><F9>,`<BE>H^Oi1G<BF>{<E3><D7>({O<8A><E7>S<91>^^^O<B9>7<BB><CD><F7><F3>C^d<E7>}r("<F8>c^P P<83> >> <D0><F3>`T^Z<ED><D2><FF>M<B2><F9>k^X^D/<8B><D5>8<A4><E1>N><A3><DD>9<C9><E7><DF><F1><F7>c^B38<9C><F7>^<BF><C2>ߕ^_<D6><F0>_<F2><BB>]<94><E7><C1><FD><E9><95>^A3<<9E>^\<B0>{\^O0<CC><C9>)<CA>r<84><D9>j^H<B3><DC><F9><F3><EF><B7><FE> <8C><E1>'L^Q<C9>"<F0><A7>"><E8><FF><DD>^^V^R<A4><D6><FC>d<EB>j*oHO<D5>^F<C2>p<D0>^U<82><EF>^Y!<90><9D>O5;:^TgL<F9>^Y<D3>z<D5>#=<81><E1><C3>6<C4>^\u%<85>7<EE>^Jaf^D0C<8B><8C>r^D^E<9D><B5>^W^L<A3>dx<FA><A3>1<FE><88>l^OO<AB>^Z<80>^\~^I<EE><DE>^O>]V~c<C9>^D<B7><88>[4|0^R<89><B5>ʳ<96><D7>Ӽ<E7><F9>^D<EB>^<BF><A5><9B>Mr^Ht<CC>A^PP<EF> >> <8D>n<BA><89>q<91><DE> > > This looks compressed to me. > > > Yes. > > David > > vedant > > >> >> -Eli >> >> On 6/27/2017 2:32 PM, Xinliang David Li wrote: >>> I had an old build of llc with FE instrumentation, the name section size is about 5MB. Using coverage is likely to cause the name section to be larger as there are more references to dead/unused function names. >>> >>> What do you see when >>> >>> readelf --string-dump=__llvm_prf_names llc >>> >>> David >>> >>> On Tue, Jun 27, 2017 at 2:23 PM, Xinliang David Li <davidxl at google.com <mailto:davidxl at google.com>> wrote: >>> >>> >>> On Tue, Jun 27, 2017 at 2:09 PM, Friedman, Eli <efriedma at codeaurora.org <mailto:efriedma at codeaurora.org>> wrote: >>> On 6/27/2017 1:47 PM, Xinliang David Li wrote: >>>> >>>> >>>> On Mon, Jun 26, 2017 at 7:24 PM, Friedman, Eli <efriedma at codeaurora.org <mailto:efriedma at codeaurora.org>> wrote: >>>> On 6/19/2017 7:29 PM, Vedant Kumar wrote: >>>>> >>>>>>> We can reduce testing time by *not* instrumented basic tools like count, not, FileCheck etc. I filed: llvm.org/PR33501 <http://llvm.org/PR33501>. >>>>>>> >>>>>>>> 3. The generated profile information takes up a lot of space: llc generates a 90MB profraw file. >>>>>>> >>>>>>> I don't have any ideas about how to fix this. You can decrease the space overhead for raw profiles by altering LLVM_PROFILE_MERGE_POOL_SIZE from 4 to a lower value. >>>>>> >>>>>> 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. >>>>> >>>>> You can speed up "make check" a bit by using non-instrumented versions of count, not, FileCheck, etc. >>>> >>>> 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. >>>> >>>> >>>> Can you check if name compression is turned on in your build? >>>> >>>> David >>>> >>> >>> 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. >>> >>> >>> 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. >>> >>> David >>> >>> -Eli >>> -- >>> Employee of Qualcomm Innovation Center, Inc. >>> Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project >>> >>> >> >> -- >> Employee of Qualcomm Innovation Center, Inc. >> Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project > >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20170627/4c3ea92f/attachment.html>
Friedman, Eli via llvm-dev
2017-Jun-27 22:20 UTC
[llvm-dev] My experience using -DLLVM_BUILD_INSTRUMENTED_COVERAGE to generate coverage
On 6/27/2017 2:41 PM, vsk at apple.com wrote:> With llc, the size of the names section can vary widely depending on > the value of -DLLVM_TARGETS_TO_BUILD.I'm using the default set of targets for now (DLLVM_TARGETS_TO_BUILD not specified).> Enabling coverage shouldn't increase the name section size much. > I only see one place where this happens, and it's relatively cold: > http://lab.llvm.org:8080/coverage/coverage-reports/llvm/coverage/Users/buildslave/jenkins/sharedspace/clang-stage2-coverage-R at 2/llvm/lib/Transforms/Instrumentation/InstrProfiling.cpp.html#L512Are you sure it's actually rare in practice? I can get roughly 20KB of data in the name section of an object file just by including llvm/IR/Module.h (without any other code in the file). I'll experiment a bit more. -Eli> > >> On Jun 27, 2017, at 2:40 PM, Friedman, Eli <efriedma at codeaurora.org >> <mailto:efriedma at codeaurora.org>> wrote: >> >> I get a bunch of unreadable binary. Output piped to "less": >> >> String dump of section '__llvm_prf_names': >> [ 2] >> #<CA>^Ex<DA><D4>is<E3>(^Z<EF>^O<DD>^P<A9><D5><F7><9B><CB><FB><A8>d<97>^U<96>O<9F><89><FB><85>AQ<B4>M<B5><B6>&)Wy~<FD>C^B\<B0>/$<A5><EA>s<E3><CE>L<97>E$^R<89>Dn<C8>L<84><FF> >> <EF><C7>h<B7><FB><DC>ߊ,=<BC><BF>$ow~<B0>\<C4><FF>_X<FE><E0><C7><D1>&<C9>c<F4><E7>^_<AB><B0><F9>,`<BE>H^Oi1G<BF>{<E3><D7>({O<8A><E7>S<91>^^^O<B9>7<BB><CD><F7><F3>C^d<E7>}r("<F8>c^P >> P<83> >> <D0><F3>`T^Z<ED><D2><FF>M<B2><F9>k^X^D/<8B><D5>8<A4><E1>N><A3><DD>9<C9><E7><DF><F1><F7>c^B38<9C><F7>^<BF><C2>ߕ^_<D6><F0>_<F2><BB>]<94><E7><C1><FD><E9><95>^A3<<9E>^\<B0>{\^O0<CC><C9>)<CA>r<84><D9>j^H<B3><DC><F9><F3><EF><B7><FE> >> <8C><E1>'L^Q<C9>"<F0><A7>"><E8><FF><DD>^^V^R<A4><D6><FC>d<EB>j*oHO<D5>^F<C2>p<D0>^U<82><EF>^Y!<90><9D>O5;:^TgL<F9>^Y<D3>z<D5>#=<81><E1><C3>6<C4>^\u%<85>7<EE>^Jaf^D0C<8B><8C>r^D^E<9D><B5>^W^L<A3>dx<FA><A3>1<FE><88>l^OO<AB>^Z<80>^\~^I<EE><DE>^O>]V~c<C9>^D<B7><88>[4|0^R<89><B5>ʳ<96><D7>Ӽ<E7><F9>^D<EB>^<BF><A5><9B>Mr^Ht<CC>A^PP<EF> >> <8D>n<BA><89>q<91><DE> > > This looks compressed to me. > > vedant > > >> >> -Eli >> >> On 6/27/2017 2:32 PM, Xinliang David Li wrote: >>> I had an old build of llc with FE instrumentation, the name section >>> size is about 5MB. Using coverage is likely to cause the name >>> section to be larger as there are more references to dead/unused >>> function names. >>> >>> What do you see when >>> >>> readelf --string-dump=__llvm_prf_names llc >>> >>> David >>> >>> On Tue, Jun 27, 2017 at 2:23 PM, Xinliang David Li >>> <davidxl at google.com <mailto:davidxl at google.com>> wrote: >>> >>> >>> >>> On Tue, Jun 27, 2017 at 2:09 PM, Friedman, Eli >>> <efriedma at codeaurora.org <mailto:efriedma at codeaurora.org>> wrote: >>> >>> On 6/27/2017 1:47 PM, Xinliang David Li wrote: >>>> >>>> >>>> On Mon, Jun 26, 2017 at 7:24 PM, Friedman, Eli >>>> <efriedma at codeaurora.org <mailto:efriedma at codeaurora.org>> >>>> wrote: >>>> >>>> On 6/19/2017 7:29 PM, Vedant Kumar wrote: >>>>> >>>>>>> We can reduce testing time by *not* instrumented >>>>>>> basic tools like count, not, FileCheck etc. I filed: >>>>>>> llvm.org/PR33501 <http://llvm.org/PR33501>. >>>>>>> >>>>>>>> 3. The generated profile information takes up a lot >>>>>>>> of space: llc generates a 90MB profraw file. >>>>>>> >>>>>>> I don't have any ideas about how to fix this. You >>>>>>> can decrease the space overhead for raw profiles by >>>>>>> altering LLVM_PROFILE_MERGE_POOL_SIZE from 4 to a >>>>>>> lower value. >>>>>> >>>>>> 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. >>>>> >>>>> You can speed up "make check" a bit by using >>>>> non-instrumented versions of count, not, FileCheck, etc. >>>> >>>> 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. >>>> >>>> >>>> Can you check if name compression is turned on in your build? >>>> >>>> David >>>> >>> >>> 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. >>> >>> >>> >>> 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. >>> >>> David >>> >>> >>> -Eli >>> >>> -- >>> Employee of Qualcomm Innovation Center, Inc. >>> Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project >>> >>> >>> >> >> -- >> Employee of Qualcomm Innovation Center, Inc. >> Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project >-- Employee of Qualcomm Innovation Center, Inc. Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20170627/482c6748/attachment-0001.html>
via llvm-dev
2017-Jun-27 22:38 UTC
[llvm-dev] My experience using -DLLVM_BUILD_INSTRUMENTED_COVERAGE to generate coverage
> On Jun 27, 2017, at 3:20 PM, Friedman, Eli <efriedma at codeaurora.org> wrote: > > On 6/27/2017 2:41 PM, vsk at apple.com <mailto:vsk at apple.com> wrote: >> With llc, the size of the names section can vary widely depending on the value of -DLLVM_TARGETS_TO_BUILD. > > I'm using the default set of targets for now (DLLVM_TARGETS_TO_BUILD not specified). > >> Enabling coverage shouldn't increase the name section size much. I only see one place where this happens, and it's relatively cold: >> http://lab.llvm.org:8080/coverage/coverage-reports/llvm/coverage/Users/buildslave/jenkins/sharedspace/clang-stage2-coverage-R at 2/llvm/lib/Transforms/Instrumentation/InstrProfiling.cpp.html#L512 <http://lab.llvm.org:8080/coverage/coverage-reports/llvm/coverage/Users/buildslave/jenkins/sharedspace/clang-stage2-coverage-R at 2/llvm/lib/Transforms/Instrumentation/InstrProfiling.cpp.html#L512> > Are you sure it's actually rare in practice? I can get roughly 20KB of data in the name section of an object file just by including llvm/IR/Module.h (without any other code in the file).Hm, I looked at CoverageMappingGen.cpp.o and found that enabling coverage increases the size of the profile names section from 21K to 254K. It's more common than I expected. vedant> > I'll experiment a bit more. > > -Eli > >> >> >>> On Jun 27, 2017, at 2:40 PM, Friedman, Eli <efriedma at codeaurora.org> wrote: >>> >>> I get a bunch of unreadable binary. Output piped to "less": >>> >>> String dump of section '__llvm_prf_names': >>> [ 2] #<CA>^Ex<DA><D4>is<E3>(^Z<EF>^O<DD>^P<A9><D5><F7><9B><CB><FB><A8>d<97>^U<96>O<9F><89><FB><85>AQ<B4>M<B5><B6>&)Wy~<FD>C^B\<B0>/$<A5><EA>s<E3><CE>L<97>E$^R<89>Dn<C8>L<84><FF> >>> <EF><C7>h<B7><FB><DC>ߊ,=<BC><BF>$ow~<B0>\<C4><FF>_X<FE><E0><C7><D1>&<C9>c<F4><E7>^_<AB><B0><F9>,`<BE>H^Oi1G<BF>{<E3><D7>({O<8A><E7>S<91>^^^O<B9>7<BB><CD><F7><F3>C^d<E7>}r("<F8>c^P P<83> >>> <D0><F3>`T^Z<ED><D2><FF>M<B2><F9>k^X^D/<8B><D5>8<A4><E1>N><A3><DD>9<C9><E7><DF><F1><F7>c^B38<9C><F7>^<BF><C2>ߕ^_<D6><F0>_<F2><BB>]<94><E7><C1><FD><E9><95>^A3<<9E>^\<B0>{\^O0<CC><C9>)<CA>r<84><D9>j^H<B3><DC><F9><F3><EF><B7><FE> <8C><E1>'L^Q<C9>"<F0><A7>"><E8><FF><DD>^^V^R<A4><D6><FC>d<EB>j*oHO<D5>^F<C2>p<D0>^U<82><EF>^Y!<90><9D>O5;:^TgL<F9>^Y<D3>z<D5>#=<81><E1><C3>6<C4>^\u%<85>7<EE>^Jaf^D0C<8B><8C>r^D^E<9D><B5>^W^L<A3>dx<FA><A3>1<FE><88>l^OO<AB>^Z<80>^\~^I<EE><DE>^O>]V~c<C9>^D<B7><88>[4|0^R<89><B5>ʳ<96><D7>Ӽ<E7><F9>^D<EB>^<BF><A5><9B>Mr^Ht<CC>A^PP<EF> >>> <8D>n<BA><89>q<91><DE> >> >> This looks compressed to me. >> >> vedant >> >> >>> >>> -Eli >>> >>> On 6/27/2017 2:32 PM, Xinliang David Li wrote: >>>> I had an old build of llc with FE instrumentation, the name section size is about 5MB. Using coverage is likely to cause the name section to be larger as there are more references to dead/unused function names. >>>> >>>> What do you see when >>>> >>>> readelf --string-dump=__llvm_prf_names llc >>>> >>>> David >>>> >>>> On Tue, Jun 27, 2017 at 2:23 PM, Xinliang David Li <davidxl at google.com> wrote: >>>> >>>> >>>> On Tue, Jun 27, 2017 at 2:09 PM, Friedman, Eli <efriedma at codeaurora.org> wrote: >>>> On 6/27/2017 1:47 PM, Xinliang David Li wrote: >>>>> >>>>> >>>>> On Mon, Jun 26, 2017 at 7:24 PM, Friedman, Eli <efriedma at codeaurora.org> wrote: >>>>> On 6/19/2017 7:29 PM, Vedant Kumar wrote: >>>>>> >>>>>>>> We can reduce testing time by *not* instrumented basic tools like count, not, FileCheck etc. I filed: llvm.org/PR33501. >>>>>>>> >>>>>>>>> 3. The generated profile information takes up a lot of space: llc generates a 90MB profraw file. >>>>>>>> >>>>>>>> I don't have any ideas about how to fix this. You can decrease the space overhead for raw profiles by altering LLVM_PROFILE_MERGE_POOL_SIZE from 4 to a lower value. >>>>>>> >>>>>>> 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. >>>>>> >>>>>> You can speed up "make check" a bit by using non-instrumented versions of count, not, FileCheck, etc. >>>>> >>>>> 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. >>>>> >>>>> >>>>> Can you check if name compression is turned on in your build? >>>>> >>>>> David >>>>> >>>> >>>> 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. >>>> >>>> >>>> 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. >>>> >>>> David >>>> >>>> -Eli >>>> >>>> -- >>>> Employee of Qualcomm Innovation Center, Inc. >>>> Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project >>>> >>>> >>>> >>> >>> >>> -- >>> Employee of Qualcomm Innovation Center, Inc. >>> Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project >>> >> > > > -- > Employee of Qualcomm Innovation Center, Inc. > Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20170627/d9e87ff3/attachment.html>