<div dir="ltr">Hi Hideto,<div><br></div><div>Thanks, it makes sense. It's similar to --print-after-all / --print-changed.</div><div><br></div><div>Best,</div><div>Stefanos</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Στις Τρί, 25 Μαΐ 2021 στις 4:45 π.μ., ο/η Hideto Ueno <<a href="mailto:uenoku.tokotoko@gmail.com">uenoku.tokotoko@gmail.com</a>> έγραψε:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">Hi all, <div><br></div><div>> Yes, I CC'd Hideto on the opening message, I should've CC'd all the contributors. If the full data is available, that would be a great start!</div><div>And thanks for the paper! I didn't know about it.</div><div><br></div><div>What I did in the last year is to dump results to temporary files at PasManager.h[0], and then look over all results. </div><div>I don't think it is a good way to accumulate the results so it is necessary to consider another way if we want the functionality in the trunk.<br><br></div><div>[0] <a href="https://github.com/llvm/llvm-project/blob/d881319cc5606baa7668405a296d0960a83a1e4c/llvm/include/llvm/IR/PassManager.h#L509" target="_blank">https://github.com/llvm/llvm-project/blob/d881319cc5606baa7668405a296d0960a83a1e4c/llvm/include/llvm/IR/PassManager.h#L509</a><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, May 25, 2021 at 6:12 AM Stefanos Baziotis <<a href="mailto:stefanos.baziotis@gmail.com" target="_blank">stefanos.baziotis@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">Hi Johannes,<div><br></div><div>Yes, I CC'd Hideto on the opening message, I should've CC'd all the contributors. If the full data is available, that would be a great start!</div><div>And thanks for the paper! I didn't know about it.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Not to say that we should not build some functionality upstream<br>to do this regularly :)</blockquote><div><br></div><div>I have a (bad) feeling that I'll need to do a lot of drudgework to get this data, so, I might as well help to set something up if other people are interested.</div><div>The closest thing I know is a compile-time-measurement website (?) Nikita Popov (CC'd) had set up.</div><div><br></div><div>Best,</div><div>Stefanos</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Στις Τρί, 25 Μαΐ 2021 στις 12:01 π.μ., ο/η Johannes Doerfert <<a href="mailto:johannesdoerfert@gmail.com" target="_blank">johannesdoerfert@gmail.com</a>> έγραψε:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hideto (cc'ed) did look into this last year and he has some data.<br>
You can find a quick summary in his lighting talk last year [1] and<br>
also read a little bit about it in our paper draft! (attached),<br>
especially Section 2.2 and Figure 3 are interesting here.<br>
<br>
Not to say that we should not build some functionality upstream<br>
to do this regularly :)<br>
<br>
~ Johannes<br>
<br>
[1] <a href="https://www.youtube.com/watch?v=nxfew3hsMFM&t=1435s" rel="noreferrer" target="_blank">https://www.youtube.com/watch?v=nxfew3hsMFM&t=1435s</a><br>
<br>
<br>
On 5/24/21 3:51 PM, Stefanos Baziotis via llvm-dev wrote:<br>
> Hi Min,<br>
><br>
> Honestly, I don't think optimization remarks are good to check _whether_ a<br>
> pass did any work. A far better option, to the best of my knowledge, is, as<br>
> I mentioned, the --print-after-all family [1]<br>
> Optimization remarks may help on the last question I posed and that is to<br>
> check _why_ a transformation was not applied. Although, if one reaches this<br>
> point, they will need to use way more<br>
> tools than remarks.<br>
><br>
>   And even for the Passes that use it, my impression was that not every<br>
>> predicates are annotated with optimization remarks.<br>
><br>
> Definitely not and a lot of remarks are not that descriptive either.<br>
><br>
> Best,<br>
> Stefanos<br>
><br>
> [1] <a href="https://godbolt.org/z/58Ms7qW4s" rel="noreferrer" target="_blank">https://godbolt.org/z/58Ms7qW4s</a><br>
><br>
> Στις Δευ, 24 Μαΐ 2021 στις 11:07 μ.μ., ο/η Min-Yih Hsu <<a href="mailto:minyihh@uci.edu" target="_blank">minyihh@uci.edu</a>><br>
> έγραψε:<br>
><br>
>> I think optimization remarks is a good framework for measuring whether a<br>
>> Pass does any work.<br>
>> But unfortunately it is not widely adopted by Passes outside loop<br>
>> transformations. And even for the Passes that use it, my impression was<br>
>> that not every predicates are annotated with optimization remarks.<br>
>><br>
>> -Min<br>
>><br>
>> On May 24, 2021, at 12:55 PM, Stefanos Baziotis via llvm-dev <<br>
>> <a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>> wrote:<br>
>><br>
>> Hi,<br>
>><br>
>> Has anyone gathered statistics on reference workloads (*) for<br>
>> (transformation) passes<br>
>> that are enabled / run by default (e.g., -O3) but most of the<br>
>> time _don't_ do any effective transformation?<br>
>> Even better if we also have such statistics for passes that are _not_<br>
>> enabled by default<br>
>> (e.g., loop fusion, distribution, interchange, NewGVN).<br>
>><br>
>> And yet even better if people have some idea / data for the reason for<br>
>> ineffectiveness.<br>
>> Bad heuristics / decision-making? Are some of these transformations<br>
>> useless most of the time?<br>
>> Or maybe they are useful but their implementation in LLVM is not powerful<br>
>> enough. Or maybe<br>
>> they incur a significant compile-time overhead.<br>
>><br>
>> If not, it would also be helpful if anyone who has tried gathering similar<br>
>> statistics has any<br>
>> advice on how to approach it (my rough idea is initially<br>
>> use --print-changed / --print-after-all on these workloads for -O3 and<br>
>> then try to<br>
>> slide in passes that are not enabled by default; although that's harder to<br>
>> do it right).<br>
>><br>
>> @Hideto: In the last LLVM meeting you gave a related talk [1]. Do you<br>
>> maybe have<br>
>> the full statistics and / or ways to reproduce them?<br>
>><br>
>> Best,<br>
>> Stefanos<br>
>><br>
>> (*)  SPEC, Polybench, Cryptographic libraries, Genome alignment, Image<br>
>> Processing, Graph Processing, Web browsers, databases like sqlite etc.<br>
>><br>
>> [1] <a href="https://www.youtube.com/watch?v=QvF68tOt_w8" rel="noreferrer" target="_blank">https://www.youtube.com/watch?v=QvF68tOt_w8</a><br>
>> _______________________________________________<br>
>> LLVM Developers mailing list<br>
>> <a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a><br>
>> <a href="https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank">https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br>
>><br>
>><br>
>><br>
><br>
> _______________________________________________<br>
> LLVM Developers mailing list<br>
> <a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a><br>
> <a href="https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank">https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br>
</blockquote></div>
</blockquote></div>
</blockquote></div>