Fri, May 22
Wed, May 20
In BranchProbabilityInfo::calcMetadataWeights() rephrased one comment and added one TODO.
Sun, May 17
Fri, May 15
Please review again.
Thu, May 14
Fixed bug in BranchProbabilityInfo::calcMetadataWeights() to keep total probability close to 1.0. Added a new testcase for this and fixed another one.
Wed, May 13
Tue, May 12
Thu, May 7
Wed, May 6
Mon, May 4
Fri, May 1
addressed the comments about the test
Apr 24 2020
Does the new test TEST(BasicBlockUtils, SplitIndirectBrCriticalEdge) fail ..
Yes. It fails with 100% on both edges.
Mar 25 2020
Nov 5 2019
Oct 27 2019
Addressed all comments.
Oct 25 2019
Oct 20 2019
Oct 18 2019
Fixed llvm/test/CodeGen/AMDGPU/llvm.amdgcn.ds.gws.init.ll as Matt suggested
Oct 17 2019
Added a simple early-cse test.
Oct 16 2019
Sep 11 2019
Aug 12 2019
Aug 7 2019
Jul 9 2019
please flip the flag to false by default and check in the rest first.
done. D64233 is landed.
Closed by commit rL365439: Prepare for making SwitchInstProfUpdateWrapper strict (authored by yrouban).
yrouban committed rG592f44a7e75b: Prepare for making SwitchInstProfUpdateWrapper strict (authored by yrouban).
Jul 8 2019
Jul 4 2019
extracted the preparation patch to the separate patch D64233.
Jul 3 2019
Changed assert(false) to llvm_unreachable() for release builds to fail on inconsistencies. Though it seems to be too strict as the code can tolerate such inconsistencies.
Jul 2 2019
What types of testing has been done ? I assume the code base now is relatively clean so it is safe to turn this on by default?
Frankly speaking I'm not 100% sure that the code is safe. There could be projects that might hit the assertion. E.g I have to fix one pass internally at Azul. I tested LLVM monorepo make check-all and our Azul Zing test suits. So, I believe that the only way to find issues is to land this check D64061 and the verifyer D61179 one by one with some reasonable interval (one week?).
Jul 1 2019
Jun 26 2019
Addressed most comments. The main changes are the following:
- added more cases to trivial-unswitch-profmd.ll
- brushed up basictest-profmd.ll
- added NewSI default case weight if the default successor was not an exit
Jun 24 2019
Please, see my comment to PR42084: https://bugs.llvm.org/show_bug.cgi?id=42084#c3.
A core of the problem is in two difference Cost-vs-Threshold checks used in analyzeBlock (Cost >= Threshold) and analyzeCall (Cost < max(1, Threshold)).
I believe a proper fix for this bug would be to use a unified Cost-vs-Threshold check everywhere.
I agree that those two checks seem to be inconsistent with each other, but I insist on my fix. It makes the method analyzeBlock() return same result (negative or positive) regardless of the flag ComputeFullInlineCost.
The root cause is that the analyzeBlock() returns different results (negative or positive) for different ComputeFullInlineCost. And the checks you mentioned if fixed could just hide this difference.
Jun 21 2019
One issue bothers me: results of the InlineCost analyzer will depend on the flag ComputeFullInlineCost. Negative or positive decision will persist but the message and highest computed cost will be changing.
We already have the cost difference depending on this flag.
It seems to be rather obvious consequence of "full inline cost" notion and the difference should not be confusing...
I still believe that we should separate a bug fix from introducing a new feature. As I read the comments this patch looks to be complex to be just a bugfix but not full enough to introduce a new and complete feature.
I could provide a one line fix with a test if I believe it is a complete fix for the bug. In other words I'm a bit stuck. Any suggestions are welcome.
Jun 20 2019
Jun 18 2019
Rebased to the latest HEAD. Please review. Its sibling patches have been landed.
Jun 17 2019
Jun 16 2019
Jun 14 2019
- extracted a separate function GetFirstNegative()
- changed the test to check that the bug is fixed
I think this is somewhat the wrong approach.
I think we need to widen the interface a bit to return two pieces of information instead of one:
- The highest cost computed
- Any inline-blocking construct encountered And we should phrase #2 as a bitmask so that we can return multiple things in it. One of them can be that we exceeded the threshold, another can be any terminal condition we additionally reached like recursion. I think this will also make the code more clear as we won't be throwing away any information at any step.
In general I agree with this approach. But the bigger change it needs the stronger intention I have to fix the bug with a minimal change and to develop the feature as another separate patch. One issue bothers me: results of the InlineCost analyzer will depend on the flag ComputeFullInlineCost. Negative or positive decision will persist but the message and highest computed cost will be changing.
Jun 11 2019
Jun 9 2019
2 questions, since i've read through the diff:
- will this pick the smallest cost, or the first negative cost?
- is this missing some abstraction? maybe InlineResult Result should be some wrapper that should be assigned-to, that will internally only accept the new value if it's better than what it currently has,
- Not the smallest cost, but the first negative result with its message.
- I think such an abstraction would not be much shorter: Result = InlineResult::FirstNegative(Result, expression)
Jun 5 2019
Interesting. I will try but next week.
Jun 4 2019
Jun 2 2019
May 31 2019
added option switch-inst-prof-update-wrapper-strict to assert if prof data is inconsistent. It is off by default.
Probably it makes sense to enable prof branch_weights validation (patch D61179) in the same way.
I suggest the following path:
- add an option to enforce internal error on inconsistency; by default the inconsistency is ignored.
Ok. This option will probably simplify catching such bugs.
May 30 2019
Formatted and fixed one typo.
What I meant is that we should never see inconsistent state and instead of setting invalid state, we assert there.
Yes. But in LLVM there are many places to fix. So we have to fix all of them at once and set the assertion here. The other option is to fix them one by one and tolerate such inconsistencies.
For example, SimplifyCFG is safe: it checks that the prof data is ok and only then makes its prof changes.
Providing an obviously incorrect branch_weights for one of the added test cases is enough to cause an assertion failure:
I have just submitted a fix. Please see D62656. Once it is landed this patch can be landed unchanged.
I decided to not include the crash test case as it would be caught by verification proposed in D61179.