Project Ortega BCM5719 LLVM https://git.raptorcs.com/git/bcm5719-llvm/atom?h=meklort-10.0.1 2020-06-24T01:45:59+00:00 2020-06-24T01:45:59+00:00 Tom Stellard tstellar@redhat.com 2020-05-09T00:34:05+00:00 urn:sha1:be4501f6e487fc27b242e0799cfeed3b4eedc4cd PR45539: https://bugs.llvm.org/show_bug.cgi?id=45539 (cherry picked from commit 01bcc3e9371470e1974f066ced353df15e10056d) 2020-06-17T03:16:13+00:00 Tom Stellard tstellar@redhat.com 2020-05-27T19:16:30+00:00 urn:sha1:4d0626a822be3cfe1809d9b3ba976e5bda0b02e4 Summary: Currently, `rewriteLoopExitValues()`'s logic is roughly as following: > Loop over each incoming value in each PHI node. > Query whether the SCEV for that incoming value is high-cost. > Expand the SCEV. > Perform sanity check (`isValidRewrite()`, D51582) > Record the info > Afterwards, see if we can drop the loop given replacements. > Maybe perform replacements. The problem is that we interleave SCEV cost checking and expansion. This is A Problem, because `isHighCostExpansion()` takes special care to not bill for the expansions that were already expanded, and we can reuse. While it makes sense in general - if we know that we will expand some SCEV, all the other SCEV's costs should account for that, which might cause some of them to become non-high-cost too, and cause chain reaction. But that isn't what we are doing here. We expand *all* SCEV's, unconditionally. So every next SCEV's cost will be affected by the already-performed expansions for previous SCEV's. Even if we are not planning on keeping some of the expansions we performed. Worse yet, this current "bonus" depends on the exact PHI node incoming value processing order. This is completely wrong. As an example of an issue, see @dmajor's `pr45835.ll` - if we happen to have a PHI node with two(!) identical high-cost incoming values for the same basic blocks, we would decide first time around that it is high-cost, expand it, and immediately decide that it is not high-cost because we have an expansion that we could reuse (because we expanded it right before, temporarily), and replace the second incoming value but not the first one; thus resulting in a broken PHI. What we instead should do for now, is not perform any expansions until after we've queried all the costs. Later, in particular after `isValidRewrite()` is an assertion (D51582) we could improve upon that, but in a more coherent fashion. See [[ https://bugs.llvm.org/show_bug.cgi?id=45835 | PR45835 ]] Reviewers: dmajor, reames, mkazantsev, fhahn, efriedma Reviewed By: dmajor, mkazantsev Subscribers: smeenai, nikic, hiraditya, javed.absar, llvm-commits, dmajor Tags: #llvm Differential Revision: https://reviews.llvm.org/D79787 (cherry picked from commit b2df96123198deadad74634c978e84912314da26) 2020-05-19T01:54:45+00:00 Florian Hahn flo@fhahn.com 2020-05-07T18:42:19+00:00 urn:sha1:bace7beb530db8bd6ac79aa6e9f1323b3e52e38b Summary: NOTE: I mostly put it on Phabricator to make it easy for other people to fetch & check if that fixes a bug. This patch backports 4878aa36d4a and required earlier patches onto the release/10.x branch. It includes the following patches: aa5ebfdf205de6d599c1fed3161da3b63b6f0bef [ValueLattice] Make mark* functions public, return if value changed. c1943b42c5b7feff5d0e0c1358d02889e2be165f [ValueLattice] Update markConstantRange to return false equal ranges. e30c257811f62fea21704caa961c61e4559de202 [CVP,SCCP] Precommit test for D75055. 4878aa36d4aa27df644430139fab2734fde4a000 [ValueLattice] Add new state for undef constants. All patches except the last one apply cleanly. For the last one, the changes to SCCP.cpp were stripped, because SCCP does not yet use ValueLattice on release/10.x. Otherwise we would have to pull in more additional changes. Subscribers: tstellar, hiraditya, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D76596 2020-04-30T00:13:34+00:00 Jun Ma JunMa@linux.alibaba.com 2020-03-18T03:42:16+00:00 urn:sha1:e4312b950dd7b019e14b991a17d6ac260b8e8082 For now, when final suspend can be simplified by simplifySuspendPoint, handleFinalSuspend is executed as well to remove last case in switch instruction. This patch fixes it. Differential Revision: https://reviews.llvm.org/D76345 (cherry picked from commit 032251e34d17c1cbf21e7571514bb775ed5cdf30) 2020-04-16T18:12:13+00:00 Jonas Paulsson paulsson@linux.vnet.ibm.com 2020-03-04T16:11:40+00:00 urn:sha1:5fbba36cbe93f12da5c4d6063db21cf35ecc9bfc SimplifyCFG should not merge empty return blocks and leave a CallBr behind with a duplicated destination since the verifier will then trigger an assert. This patch checks for this case and avoids the transformation. CodeGenPrepare has a similar check which also has a FIXME comment about why this is needed. It seems perhaps better if these two passes would eventually instead update the CallBr instruction instead of just checking and avoiding. This fixes https://bugs.llvm.org/show_bug.cgi?id=45062. Review: Craig Topper Differential Revision: https://reviews.llvm.org/D75620 (cherry picked from commit c2dafe12dc24f7f1326f5c4c6a3b23f1485f1bd6) 2020-03-19T09:12:16+00:00 Hans Wennborg hans@chromium.org 2020-03-19T09:12:16+00:00 urn:sha1:5401d393f88b9fa99a8d3a2a1b3013e757d958a2 2020-03-19T09:02:25+00:00 Sanjay Patel spatel@rotateright.com 2020-02-10T22:13:26+00:00 urn:sha1:623461b2ce421cd287f1bea50c0998003375a782 As discussed in PR41083: https://bugs.llvm.org/show_bug.cgi?id=41083 ...we can assert/crash in EarlyCSE using the current hashing scheme and instructions with flags. ValueTracking's matchSelectPattern() may rely on overflow (nsw, etc) or other flags when detecting patterns such as min/max/abs composed of compare+select. But the value numbering / hashing mechanism used by EarlyCSE intersects those flags to allow more CSE. Several alternatives to solve this are discussed in the bug report. This patch avoids the issue by doing simple matching of min/max/abs patterns that never requires instruction flags. We give up some CSE power because of that, but that is not expected to result in much actual performance difference because InstCombine will canonicalize these patterns when possible. It even has this comment for abs/nabs: /// Canonicalize all these variants to 1 pattern. /// This makes CSE more likely. (And this patch adds PhaseOrdering tests to verify that the expected transforms are still happening in the standard optimization pipelines. I left this code to use ValueTracking's "flavor" enum values, so we don't have to change the callers' code. If we decide to go back to using the ValueTracking call (by changing the hashing algorithm instead), it should be obvious how to replace this chunk. Differential Revision: https://reviews.llvm.org/D74285 (cherry picked from commit b8ebc11f032032c7ca449f020a1fe40346e707c8) 2020-03-19T09:02:25+00:00 Sanjay Patel spatel@rotateright.com 2020-02-10T20:10:47+00:00 urn:sha1:cfa792458fc47f9890d94a2718288c269c8a2a6e Test that instcombine and early-cse can cooperate to reduce sequences of select patterns that are not composed of the same underlying instructions. There's a bug in EarlyCSE (PR41083), and we can test how much a possible fix (D74285) may affect optimization. (cherry picked from commit 0ad6e726ec7eee8ef14a89fa288d5a1420d96b1e) 2020-03-02T10:38:20+00:00 Reid Kleckner rnk@google.com 2020-03-01T15:47:55+00:00 urn:sha1:0bf4795d069642afe2a430521f3549e425f092c9 getFirstInsertionPt's return value must be checked for validity before casting it to Instruction*. Don't attempt to insert casts after a phi in a catchswitch block. Fixes PR45033, introduced in D37832. Reviewed By: davidxl, hfinkel Differential Revision: https://reviews.llvm.org/D75381 (cherry picked from commit 1adbe86d87bd4ecffc73ab17c7da56f44816f424) 2020-02-28T10:27:33+00:00 Hans Wennborg hans@chromium.org 2020-02-27T16:01:09+00:00 urn:sha1:7cb6829291280a2adcc260346a7a56b8bddd43db SROA will drop the explicit alignment on allocas when the ABI guarantees enough alignment. Because the alignment on new load/store instructions are set based on the alloca's alignment, that means SROA would end up dropping the alignment from atomic loads and stores, which is not allowed (see bug). For those, make sure to always carry over the alignment from the previous instruction. Differential revision: https://reviews.llvm.org/D75266 (cherry picked from commit d48c981697a49653efff9dd14fa692d99e6fa868)