[PATCH] D86657: Add new hidden option -print-crash-IR that prints out IR that caused opt pipeline to crash

Fri Oct 1 16:35:47 PDT 2021

aeubanks added a comment.

In D86657#3037681 <https://reviews.llvm.org/D86657#3037681>, @DaniilSuchkov wrote:

> In D86657#3037670 <https://reviews.llvm.org/D86657#3037670>, @aeubanks wrote:
>
>> The title needs updating for the option name
>>
>> Btw I just tried this on a very large file with a (real) LLVM crash and it was very slow and I gave up. It's probably from printing the IR after every pass. Perhaps cloning the module via `CloneModule()` and keeping that around might be faster?
>
> Keep in mind that:
> a) This is still (supposedly) a quality of life improvement over using `-print-after-all -print-module-scope`. In my experience `-print-after-all -print-module-scope` in some cases can take hours (and then I have to deal with a few GB long log).

The current implementation isn't that much better than just `-print-after-all -print-module-scope`. It's easy to look at a huge log, search for the last instance of "IR Dump", and delete everything from that to the beginning of the file. I think making this quick is very important for it to be much more useful than `-print-after-all -print-module-scope`.
For example, I had a repro that took 2 seconds to crash. I tried specifying (with this patched in) `--print-on-crash`, and gave up after several minutes. If could keep the slowdown of turning this on within an order of magnitude of the original repro that'd be super useful.

> b) There are bugs that can corrupt IR in other modules (like the one I fixed here: D110752 <https://reviews.llvm.org/D110752>), so keeping a live `Module` object isn't the best idea.

D110752 <https://reviews.llvm.org/D110752> is not corrupting IR, it happened because we were looking at a constant's users, which is not a thing that makes sense to do (e.g. look at all users of the constant `false`).

> Serializing the module into the binary representation and then de-serizalining and printing it upon crash is an option, though I'm not sure it's robust enough, since the LLVMContext can be arbitrarily broken at that point.

I guess it's possible that LLVMContext is broken, but that's much rarer than simply seeing a random crash in a pass. I don't think it's worth handling the small chance that something fundamental is broken to slow down the common use case.

But again, still fine to land this and improve on it later if you'd like.

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D86657/new/

https://reviews.llvm.org/D86657