- User Since
- Oct 28 2019, 10:35 AM (46 w, 6 d)
Thu, Sep 17
I've filed an issue for a performance regression caused by this patch:
Aug 11 2020
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.
Aug 10 2020
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!
Aug 9 2020
Aug 6 2020
Aug 1 2020
Self LGTM as this one is an obvious NFC.
Jul 28 2020
Spun off the llvm-readobj bit.
Jul 27 2020
Jul 23 2020
Jul 1 2020
Jun 11 2020
Jun 4 2020
Jun 2 2020
Thank you two for reviews!
Jun 1 2020
Made the last parameter of shouldInline optional.
May 28 2020
May 27 2020
May 25 2020
May 21 2020
May 20 2020
May 19 2020
May 11 2020
May 5 2020
May 4 2020
I've updated the patch to turn off the new cost calculation by default.
Apr 30 2020
I've renamed SecondaryUsers to NumCallerUsers.
Apr 29 2020
Apr 7 2020
Mar 30 2020
LGTM. Thank you for revising the patch!
Mar 29 2020
It looks like the testcase can be reduced to the following. You can check for no jump threading occurring:
Mar 19 2020
Incorporated feedback from efriedma to use llvm::is_contained instead
Mar 18 2020
Mar 16 2020
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.
Mar 13 2020
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!
Mar 6 2020
Hi @maxim-kuvyrkov, would you mind filing two separate issues -- the size and performance -- preferably with preprocessed source code? Thanks!
Feb 18 2020
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.
Feb 5 2020
I've fixed the confusing debug message that Wei has pointed out.
Feb 3 2020
I've fixed several bugs. PTAL Thanks!
Jan 28 2020
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
I am re-opening this so that I can check in a revised version.
Jan 23 2020
Jan 17 2020
I echo what other have said.
Jan 16 2020
I've further simplied thread-two-bbs3.ll, the testcase for Windows,
and made it a little more robust with:
Jan 15 2020
I'm abandoning this change. We'll discuss the revision in https://reviews.llvm.org/D70247 instead.
I'm reopening this so that I can upload a revision containing a fix for Windows build.
Jan 13 2020
Jan 8 2020
I've reverted the change for now. I'll take a look at the failure on Windows.
Jan 7 2020
Please take a look. Thanks!
Updated the patch, incorporating feedback from Wei.
Dec 30 2019
https://reviews.llvm.org/D71733 supersedes this patch.
Dec 20 2019
Dec 17 2019
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.