Project Ortega BCM5719 LLVM https://git.raptorcs.com/git/bcm5719-llvm/atom?h=meklort-10.0.0 2020-03-19T09:02:25+00:00 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-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) 2020-02-26T15:13:01+00:00 Philip Reames listmail@philipreames.com 2020-02-25T16:56:53+00:00 urn:sha1:48d24465668b268ec0aa39b62cabab5ee50e961d This reverts commit 8d22100f66c4170510c6ff028c60672acfe1cff9. There was a functional regression reported (https://bugs.llvm.org/show_bug.cgi?id=44996). I'm not actually sure the patch is wrong, but I don't have time to investigate currently, and this line of work isn't something I'm likely to get back to quickly. (cherry picked from commit 14845b2c459021e3dbf2ead52d707d4a7db40cbb) 2020-02-26T09:06:30+00:00 Alina Sbirlea asbirlea@google.com 2020-02-13T18:49:44+00:00 urn:sha1:8b0df8e1ed6842095388fce08a0a5f761cd905ed Summary: Potential fix for: https://bugs.llvm.org/show_bug.cgi?id=44889 and https://bugs.llvm.org/show_bug.cgi?id=44408 In the legacy pass manager, loop rotate need not compute MemorySSA when not being in the same loop pass manager with other loop passes. There isn't currently a way to differentiate between the two cases, so this attempts to limit the usage in LoopRotate to only update MemorySSA when the analysis is already available. The side-effect of this is that it will split the Loop pipeline. This issue does not apply to the new pass manager, where we have a flag specifying if all loop passes in that loop pass manager preserve MemorySSA. Reviewers: dmgreen, fedor.sergeev, nikic Subscribers: Prazek, hiraditya, george.burgess.iv, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D74574 (cherry picked from commit 1326a5a4cfe004181f2ec8231d84ecda2b93cb25) 2020-02-21T08:51:47+00:00 Bill Wendling isanbard@gmail.com 2020-02-21T00:22:35+00:00 urn:sha1:da0fe2ade369223ebea2dafd411746e854a801f2 Similarly to how splitting predecessors with an indirectbr isn't handled in the generic way, we also shouldn't split callbrs, for similar reasons. (cherry picked from commit 2fe457690da0fc38bc7f9f1d0aee2ba6a6a16ada) 2020-01-11T11:57:29+00:00 Nuno Lopes nunoplopes@sapo.pt 2020-01-11T11:57:29+00:00 urn:sha1:87407fc03c82d880cc42330a8e230e7a48174e3c 2020-01-09T16:18:36+00:00 Whitney Tsang whitneyt@ca.ibm.com 2020-01-09T16:15:53+00:00 urn:sha1:d27a15fed79c8e8484825ce6c3ce1682daeb1547 pass. Summary: This patch changes LoopUnrollAndJamPass to a function pass, and keeps the loops traversal order same as defined in FunctionToLoopPassAdaptor LoopPassManager.h. The next patch will change the loop traversal to outer to inner order, so more loops can be transform. Discussion in llvm-dev mailing list: https://groups.google.com/forum/#!topic/llvm-dev/LF4rUjkVI2g Reviewer: dmgreen, jdoerfert, Meinersbur, kbarton, bmahjour, etiotto Reviewed By: dmgreen Subscribers: hiraditya, zzheng, llvm-commits Tag: LLVM Differential Revision: https://reviews.llvm.org/D72230 2020-01-09T10:52:52+00:00 Florian Hahn flo@fhahn.com 2020-01-09T10:23:34+00:00 urn:sha1:ccf24225e3f2356ebf0e73bb114a831bf1721222 This patch updates the shape propagation to iterate until no new shape information is discovered. As initial seed for the forward propagation, we use the matrix intrinsic instructions. Both propagateShapeForward and propagateShapeBackward return new work lists, with the instructions to be used for the next iteration. When propagating forward, we record all instructions we added new shape information for. When propagating backward, we record all users of instructions we added new shape information for. Reviewers: anemet, Gerolf, reames, hfinkel, andrew.w.kaylor Reviewed By: anemet Differential Revision: https://reviews.llvm.org/D70901 2020-01-09T10:21:20+00:00 Florian Hahn flo@fhahn.com 2020-01-09T09:52:04+00:00 urn:sha1:7adf6644f50a60a25f81c976b0f3a08320a63665 This patch extends to shape propagation to also include load instructions and implements shape aware lowering for vector loads. Reviewers: anemet, Gerolf, reames, hfinkel, andrew.w.kaylor Reviewed By: anemet Differential Revision: https://reviews.llvm.org/D70900 2020-01-09T09:48:07+00:00 Florian Hahn flo@fhahn.com 2020-01-09T09:47:26+00:00 urn:sha1:459ad8e97e07c823181cd457f2c2ac08f3896e37 This patch extends the shape propagation for matrix operations to also propagate the shape of instructions to their operands. Reviewers: anemet, Gerolf, reames, hfinkel, andrew.w.kaylor Reviewed By: anemet Differential Revision: https://reviews.llvm.org/D70899