Brian Gesiak via llvm-dev
2017-Jun-27 18:48 UTC
[llvm-dev] Next steps for optimization remarks?
Adam, thanks for all the suggestions! One nice aspect of the `-Rpass` family of options is that I can filter based on what I want. If I only want to see which inlines I missed, I could use `clang -Rpass-missed="inline"`, for example. On the other hand, optimization remark YAML always include remarks from all passes (as far as I can tell), which increases the amount of time it takes opt-viewer.py and other tools to parse. Would you be open to including options to, for example, only emit optimization remarks related to loop vectorization, or to not emit any analysis remarks? Or is it important that the YAML always include all remarks? Let me know what you think! In the meantime, I'll try to add the progress bar you mention in llvm.org/PR33522. Thanks! - Brian Gesiak -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20170627/2000005c/attachment.html>
Hal Finkel via llvm-dev
2017-Jun-28 15:13 UTC
[llvm-dev] Next steps for optimization remarks?
On 06/27/2017 01:48 PM, Brian Gesiak via llvm-dev wrote:> Adam, thanks for all the suggestions! > > One nice aspect of the `-Rpass` family of options is that I can filter > based on what I want. If I only want to see which inlines I missed, I > could use `clang -Rpass-missed="inline"`, for example. On the other > hand, optimization remark YAML always include remarks from all passes > (as far as I can tell), which increases the amount of time it takes > opt-viewer.py and other tools to parse. Would you be open to including > options to, for example, only emit optimization remarks related to > loop vectorization, or to not emit any analysis remarks? Or is it > important that the YAML always include all remarks?I don't object to adding some kind of filtering option, but in general it won't help. An important goal here is to provide analysis (and other) tools to users that present this information at a higher level. The users won't, and shouldn't, know exactly what kinds of messages the tools use. This is already somewhat true for llvm-opt-report, and will be even more true in the future. -Hal> > Let me know what you think! In the meantime, I'll try to add the > progress bar you mention in llvm.org/PR33522 > <http://llvm.org/PR33522>. Thanks! > > - Brian Gesiak > > > _______________________________________________ > LLVM Developers mailing list > llvm-dev at lists.llvm.org > http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev-- Hal Finkel Lead, Compiler Technology and Programming Languages Leadership Computing Facility Argonne National Laboratory -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20170628/81b56e80/attachment.html>
Brian Gesiak via llvm-dev
2017-Jun-28 18:56 UTC
[llvm-dev] Next steps for optimization remarks?
> On Wed, Jun 28, 2017 at 8:13 AM, Hal Finkel <hfinkel at anl.gov> wrote: > > I don't object to adding some kind of filtering option, but in general it won't help. An important goal here is to provide analysis (and other) tools to users that present this information at a higher level. The users won't, and shouldn't, know exactly what kinds of messages the tools use. This is already somewhat true for llvm-opt-report, and will be even more true in the future.Ah, I see, that makes sense. Thanks!> On Tue, Jun 20, 2017 at 1:50 AM, Adam Nemet <anemet at apple.com> wrote: > > We desperately need a progress bar in opt-viewer. Let me know if you want to add it otherwise I will. I filed llvm.org/PR33522 for this. > > In terms of improving the performance, I am pretty sure the bottleneck is still YAML parsing so: > > - If PGO is used, we can have a threshold to not even emit remarks on cold code, this should dramatically improve performance, llvm.org/PR33523 > - I expect that some sort of binary encoding of YAML would speed up parsing but I haven’t researched this topic yet...I added progress indicators in https://reviews.llvm.org/D34735, and it seems like it takes a while for the Python scripts to read some of the larger YAML files produced for my program. I'll try to look into binary YAML encoding later this week. A threshold preventing remarks from being emitted on cold code sounds good to me as well. Hal, do you agree, or is this also something that tools at a higher level should be responsible for ignoring? - Brian Gesiak