I've filed an issue for a performance regression caused by this patch:

I've llvm/util/update_test_checks.py to update CHECK lines.

Please thank a look. Thanks!

I've rebased this patch on top of https://reviews.llvm.org/D85684.

In D85687#2208099, @nikic wrote:

Oops, looks like we were working on this in parallel. I just submitted D85684 for the InstSimplify part of the problem.

Would you mind if I revert this patch temporarily? This patch makes it easier to trigger bugs like https://bugs.llvm.org/show_bug.cgi?id=46940. Although I don't think this patch itself is the root cause, reverting this patch would allow me to fix the bug above while the compiler is in a more usable state. Thanks!

Friendly ping.

Self LGTM as this one is an obvious NFC.

Spun off the llvm-readobj bit.

In D84473#2178167, @jhenderson wrote:

Could the llvm-readobj bit be spun off into a separate review, please. As things stand it doesn't have any of its own testing, which should be added at the same time as adding support in the tool itself. The new option is also lacking any documentation in the llvm-readobj and llvm-readelf docs.

LGTM. Thanks!

PTAL Thanks!

In D80776#2073762, @wenlei wrote:

Experiments show that inline deferral past pre-inlining slightly pessimizes the performance.

What are the performance numbers in terms of % you saw when deferral is disabled, if it's ok to share? Was it from Instr. PGO or Sample FDO? Asking because the new switch seems to cover both.

Thank you two for reviews!

PTAL Thanks!

Made the last parameter of shouldInline optional.

In D80229#2048327, @davidxl wrote:

How does it affect text size overall?

PTAL Thanks!

I've updated the patch to turn off the new cost calculation by default.

I've renamed SecondaryUsers to NumCallerUsers.

LGTM. Thank you for revising the patch!

It looks like the testcase can be reduced to the following. You can check for no jump threading occurring:

Incorporated feedback from efriedma to use llvm::is_contained instead
of llvm::find.

Sorry, the infinite recursion seems to come from EvaluateOnPredecessorEdge, a function that I recently added to support jump threading across two basic blocks. EvaluateOnPredecessorEdge does not have a guard against infinite recursion while its close cousin ComputeValueKnownInPredecessors does.

Hi junparser, your main change in JumpThreading.cpp looks good. Now, could you explain your change in removed-use.ll? To be honest, I haven't understood the original intent of the testcase. Thanks!

Hi @maxim-kuvyrkov, would you mind filing two separate issues -- the size and performance -- preferably with preprocessed source code? Thanks!

LGTM.

Thank you for catching this! I meant to handle PredBB ending with a conditional branch only, but I wasn't aware that PredBB could end with an unconditional branch if its address is taken.

I've fixed the confusing debug message that Wei has pointed out.

I've fixed several bugs. PTAL Thanks!

This patch is work-in-progress, but I am uploading it now so I can
share it with wider audience. I am still working on fixing loose
ends.

I am re-opening this so that I can check in a revised version.

I echo what other have said.

PTAL Thanks!

I've further simplied thread-two-bbs3.ll, the testcase for Windows,
and made it a little more robust with:

I'm abandoning this change. We'll discuss the revision in https://reviews.llvm.org/D70247 instead.

PTAL Thanks!

I'm reopening this so that I can upload a revision containing a fix for Windows build.

I've reverted the change for now. I'll take a look at the failure on Windows.

Please take a look. Thanks!

Updated the patch, incorporating feedback from Wei.

https://reviews.llvm.org/D71733 supersedes this patch.

I've updated the patch so that we commit to jump threading across two
basic blocks once we are done with analysis. That is, we don't
transform the IR partially only to see jump threading proper failing.