Project Ortega BCM5719 LLVM https://git.raptorcs.com/git/bcm5719-llvm/atom?h=meklort-10.0.1 2019-10-11T05:30:18+00:00 2019-10-11T05:30:18+00:00 Chen Zheng czhengsz@cn.ibm.com 2019-10-11T05:30:18+00:00 urn:sha1:c6c6f717af9fb38943cc0403be33678d32508932 llvm-svn: 374514 2019-10-11T05:13:56+00:00 Chen Zheng czhengsz@cn.ibm.com 2019-10-11T05:13:56+00:00 urn:sha1:c17c5864fff66e8350c6a3a85a5604f2950055ac This patch recognizes popcount intrinsic according to algorithm from website http://graphics.stanford.edu/~seander/bithacks.html#CountBitsSetParallel Differential Revision: https://reviews.llvm.org/D68189 llvm-svn: 374512 2019-04-17T04:52:47+00:00 Eric Christopher echristo@gmail.com 2019-04-17T04:52:47+00:00 urn:sha1:cee313d288a4faf0355d76fb6e0e927e211d08a5 The reversion apparently deleted the test/Transforms directory. Will be re-reverting again. llvm-svn: 358552 2019-04-17T02:12:23+00:00 Eric Christopher echristo@gmail.com 2019-04-17T02:12:23+00:00 urn:sha1:a86343512845c9c1fdbac865fea88aa5fce7142a As it's causing some bot failures (and per request from kbarton). This reverts commit r358543/ab70da07286e618016e78247e4a24fcb84077fda. llvm-svn: 358546 2018-12-17T21:14:51+00:00 Sanjay Patel spatel@rotateright.com 2018-12-17T21:14:51+00:00 urn:sha1:200885e654fc1663a9bdcd3fc444c56e1a0e64ed Now, that we have funnel shift intrinsics, it should be safe to convert this form of rotate to it. In the worst case (a target that doesn't have rotate instructions), we will expand this into a branch-less sequence of ALU ops (neg/and/and/lshr/shl/or) in the backend, so it's still very likely to be a perf improvement over the original code. The motivating source code pattern for this is shown in: https://bugs.llvm.org/show_bug.cgi?id=34924 Background: I looked at several different options before deciding where to try this - instcombine, simplifycfg, CGP - because it doesn't fit cleanly anywhere AFAIK. The backend (CGP, SDAG, GlobalIsel?) is too late for what we're trying to accomplish. We want to have the IR converted before we reach things like vectorization because the reduced code can make a loop much simpler to transform. Technically, this could be included in instcombine, but it's a large pattern match that includes control-flow, so it just felt wrong to stuff into there (although I have a draft of that patch). Similarly, this could be part of simplifycfg, but all of this pattern matching is a stretch. So we're left with our relatively new dumping ground for homeless transforms: aggressive-instcombine. This only runs at -O3, but that seems like a reasonable limitation given that source code has many options to avoid this pattern (including the recently added clang intrinsics for rotates). I'm including a PhaseOrdering test because we require the teamwork of 3 passes (aggressive-instcombine, instcombine, simplifycfg) to get this into the minimal IR form that we want. That test shows a bug with the new pass manager that's independent of this change (but it will be masked if we canonicalize harder to funnel shift intrinsics in instcombine). Differential Revision: https://reviews.llvm.org/D55604 llvm-svn: 349396 2018-12-17T12:36:35+00:00 Sanjay Patel spatel@rotateright.com 2018-12-17T12:36:35+00:00 urn:sha1:beb7bb61927cd875439d0e5c4ca75b3796a1d93f As noted in D55604 - we need a test to make sure that the new intrinsic is inserted into a valid position. llvm-svn: 349347 2018-12-12T15:28:21+00:00 Sanjay Patel spatel@rotateright.com 2018-12-12T15:28:21+00:00 urn:sha1:d8ccc0e3e43e6e98437972fc4757bf7918590e49 llvm-svn: 348933 2018-05-14T13:43:32+00:00 Sanjay Patel spatel@rotateright.com 2018-05-14T13:43:32+00:00 urn:sha1:bf55e6dee136d081b0858f62fcc362d74a708894 This bug: https://bugs.llvm.org/show_bug.cgi?id=37446 ...raises another question: why do we run aggressive-instcombine before regular instcombine? llvm-svn: 332243 2018-05-09T23:08:15+00:00 Sanjay Patel spatel@rotateright.com 2018-05-09T23:08:15+00:00 urn:sha1:ac3951a7351b2a3144ad103fb3c759b9415f55f1 This is a follow-up to D45986. As suggested there, we should match the "all-bits-set" pattern in addition to "any-bits-set". This was a little more complicated than I thought it would be initially because the "and 1" instruction can be anywhere in the chain. Hopefully, the code comments make that logic understandable, but if you see a way to simplify or improve that, it's most appreciated. This transforms patterns that emerge from bitfield tests as seen in PR37098: https://bugs.llvm.org/show_bug.cgi?id=37098 I think it would also help reduce the large test from: D46336 D46595 but we need something to reassociate that case to the forms we're expecting here first. Differential Revision: https://reviews.llvm.org/D46649 llvm-svn: 331937 2018-05-01T21:02:09+00:00 Sanjay Patel spatel@rotateright.com 2018-05-01T21:02:09+00:00 urn:sha1:d2025a2e311f94b15c12852ae4163cac41e2fd47 and (or (lshr X, C), ...), 1 --> (X & C') != 0 I initially thought about implementing the minimal pattern in instcombine as mentioned here: https://bugs.llvm.org/show_bug.cgi?id=37098#c6 ...but we need to do better to catch the more general sequence from the motivating test (more than 2 bits in the compare). And a test-suite run with statistics showed that this pattern only happened 2 times currently. It would potentially happen more often if reassociation worked better (D45842), but it's probably still not too frequent? This is small enough that I didn't see a need to create a whole new class/file within AggressiveInstCombine. There are likely other relatively small matchers like what was discussed in D44266 that would slide under foldUnusualPatterns() (name suggestions welcome). We could potentially also consolidate matchers for ctpop, bswap, etc under here. Differential Revision: https://reviews.llvm.org/D45986 llvm-svn: 331311