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-06-11T23:09:24+00:00 Craig Topper craig.topper@gmail.com 2020-05-17T21:57:04+00:00 urn:sha1:2dc664d578f0e9c8ea5975eed745e322fa77bffe Bug report: https://bugs.llvm.org/show_bug.cgi?id=45291 Patch by Tomasz Miąsko Differential Revision: https://reviews.llvm.org/D80066 (cherry picked from commit 5f65faef2c61bfb5e041f74db61665f43a05e9db) 2020-05-19T02:05:26+00:00 David Spickett david.spickett@linaro.org 2020-04-23T13:40:57+00:00 urn:sha1:d9160ff3e92683be70a80b60f4139836316bd63e of a struct that cover the whole struct This can happen when the rest of the members of are zero length. Following the same pattern applied to the SROA pass in: d7f6f1636d53c3e2faf55cdf20fbb44a1a149df1 Fixes: https://bugs.llvm.org/show_bug.cgi?id=45335 Differential Revision: https://reviews.llvm.org/D78720 (cherry picked from commit 3929429347d398773577b79f7fdb780d4f7ed887) 2020-05-07T18:18:56+00:00 Calixte Denizet calixte.denizet@gmail.com 2020-04-20T08:50:30+00:00 urn:sha1:f082d91801645e999aa8b1072392f945405eafc5 Summary: When forking in several threads, the counters were written out in using the same global static variables (see GCDAProfiling.c): that leads to crashes. So when there is a fork, the counters are resetted in the child process and they will be dumped at exit using the interprocess file locking. When there is an exec, the counters are written out and in case of failures they're resetted. Reviewers: jfb, vsk, marco-c, serge-sans-paille Reviewed By: marco-c, serge-sans-paille Subscribers: llvm-commits, serge-sans-paille, dmajor, cfe-commits, hiraditya, dexonsmith, #sanitizers, marco-c, sylvestre.ledru Tags: #sanitizers, #clang, #llvm Differential Revision: https://reviews.llvm.org/D78477 (cherry picked from commit bec223a9bc4eb9747993ee9a4c1aa135c32123e6) 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: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-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)