<div dir="ltr"><a href="https://reviews.llvm.org/D95578">https://reviews.llvm.org/D95578</a> for updating HowToSubmitABug with alternatives to bugpoint (and just modernizing it in general).<br><div><br></div><div><a href="https://reviews.llvm.org/D86657">https://reviews.llvm.org/D86657</a> (not yet submitted) will dump the IR on an LLVM crash, which would be useful. Extending that to dumping the IR to a file would be even better.<br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Jan 27, 2021 at 9:06 AM Philip Reames <<a href="mailto:listmail@philipreames.com">listmail@philipreames.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"><br>
On 1/27/21 1:58 AM, Florian Hahn via llvm-dev wrote:<br>
><br>
>> On Jan 26, 2021, at 22:32, Fangrui Song <<a href="mailto:maskray@google.com" target="_blank">maskray@google.com</a>> wrote:<br>
>><br>
>> Forked the thread and changed the subject to talk about bugpoint specifically.<br>
>> CCed folks on <a href="https://bugs.llvm.org/show_bug.cgi?id=48813" rel="noreferrer" target="_blank">https://bugs.llvm.org/show_bug.cgi?id=48813</a><br>
> Thanks!<br>
><br>
>> On 2021-01-26, Arthur Eubanks via llvm-dev wrote:<br>
>>> Hi all,<br>
>>><br>
>>> We've been fixing the various remaining issues in order to turn on the new<br>
>>> pass manager for the optimization pipeline, and it's about time to turn it<br>
>>> on. (Thanks to everyone who has helped with testing and fixing the new pass<br>
>>> manager!)<br>
>>><br>
>>> <a href="https://reviews.llvm.org/D95380" rel="noreferrer" target="_blank">https://reviews.llvm.org/D95380</a> is the change that would happen, which sets<br>
>>> the CMake flag -DENABLE_EXPERIMENTAL_NEW_PASS_MANAGER=ON by default. This<br>
>>> affects anything that uses the LLVM_ENABLE_NEW_PASS_MANAGER macro, which<br>
>>> includes opt's handling of the `opt -instcombine` syntax, clang, and<br>
>>> ThinLTO in lld drivers. This does not affect the backend target-specific<br>
>>> codegen pipeline since that's mostly not been ported to use the new PM<br>
>>> infrastructure yet.<br>
>>><br>
>>> Here <<a href="https://bugs.llvm.org/show_bug.cgi?id=46649" rel="noreferrer" target="_blank">https://bugs.llvm.org/show_bug.cgi?id=46649</a>> is the umbrella bug for<br>
>>> turning on the new PM with blockers. The main one is loop unswitching on<br>
>>> divergent loop conditions is unsafe<br>
>>> <<a href="https://bugs.llvm.org/show_bug.cgi?id=48819" rel="noreferrer" target="_blank">https://bugs.llvm.org/show_bug.cgi?id=48819</a>>, which is being looked into.<br>
>>> There's also the LLVM C API and bugpoint that still use the legacy PM,<br>
>>> which can be ported later on and only block the removal of the legacy PM.<br>
>> I have heard several users said they just use<br>
>><br>
>>   bugpoint -compile-custom -compile-command=./run a.ll<br>
>>   (this usage is similar to llvm-reduce)<br>
>><br>
>> but not any other command listed on <a href="https://llvm.org/docs/Bugpoint.html" rel="noreferrer" target="_blank">https://llvm.org/docs/Bugpoint.html</a> .<br>
>> (I am among them. <a href="https://llvm.org/docs/Bugpoint.html" rel="noreferrer" target="_blank">https://llvm.org/docs/Bugpoint.html</a> and<br>
>> <a href="https://llvm.org/docs/CommandGuide/bugpoint.html" rel="noreferrer" target="_blank">https://llvm.org/docs/CommandGuide/bugpoint.html</a><br>
>> have no usage examples so I resorted to an external article<br>
>> <a href="http://logan.tw/posts/2014/11/26/llvm-bugpoint/" rel="noreferrer" target="_blank">http://logan.tw/posts/2014/11/26/llvm-bugpoint/</a> )<br>
> FWIW I often use bugpoint’s crashing pass reduction feature ( e.g. `bugpoint -O3 foo.bc` to reduce the sequence of passes exposing a crash) when investigating crashes in LLVM optimizations. This is unfortunately one of the features directly tied to the pass manager.<br>
Same.<br>
> My main concern is that `opt` and `bugpoint` having different defaults seems to have potential to be quite confusing to user  (e.g. `opt -passes=default<O3>` crashes, but `bug point -passes=default<O3>` does not, `bug point -O3 ` works, but does not reproduce the failure, e.g. due to difference in the pipeline).<br>
><br>
> I don’t know how widely used bugpoint is, but it features prominently in the documentation, e.g. <a href="https://llvm.org/docs/HowToSubmitABug.html" rel="noreferrer" target="_blank">https://llvm.org/docs/HowToSubmitABug.html</a> , which is linked from the getting started page and the documentation sidebar.<br>
><br>
> I think before switching, it would be good to at least update HowToSubmitABug. We should probably also add a note to Bugpoint’s docs and refer the the documentation for llvm-reduce. It is great if people take time to reduce the test cases for their bug reports and we should try to make the experience as smooth as possible<br>
Florian raises a great point here.  I'd be comfortable simply <br>
documenting the issue for the moment, but getting bugpoint properly <br>
ported to the new PM close to the point we switch seems very worthwhile <br>
for the reason Florian nicely describes.<br>
</blockquote></div>