Project Ortega BCM5719 LLVM https://git.raptorcs.com/git/bcm5719-llvm/atom?h=meklort-10.0.1 2020-01-15T11:44:57+00:00 2020-01-15T11:44:57+00:00 Arkady Shlykov arkady.shlykov@intel.com 2020-01-14T15:46:46+00:00 urn:sha1:019c8d9d1511a07d2004667d2240f3e47cb991ec Summary: Test case test14 is missing, adjust the numbering to have a consecutive range. Also a test commit to verify commit access. 2020-01-10T09:41:41+00:00 Sjoerd Meijer sjoerd.meijer@arm.com 2020-01-10T09:41:41+00:00 urn:sha1:356685a1d8972180f472c1333e8e89dbcc704c1d 2020-01-10T09:35:00+00:00 Sjoerd Meijer sjoerd.meijer@arm.com 2020-01-10T09:30:02+00:00 urn:sha1:67bf9a6154d4b82c6c01aad01141bf08c1bbd0f6 Teach SCEV about the @loop.decrement.reg intrinsic, which has exactly the same semantics as a sub expression. This allows us to query hardware-loops, which contain this @loop.decrement.reg intrinsic, so that we can calculate iteration counts, exit values, etc. of hardwareloops. This "int_loop_decrement_reg" intrinsic is defined as "IntrNoDuplicate". Thus, while hardware-loops and tripcounts now become analysable by SCEV, this prevents the usual loop transformations from applying transformations on hardware-loops, which is what we want at this point, for which I have added test cases for loopunrolling and IndVarSimplify and LFTR. Differential Revision: https://reviews.llvm.org/D71563 2020-01-09T11:57:34+00:00 Sam Parker sam.parker@arm.com 2020-01-09T11:57:04+00:00 urn:sha1:15c7fa4d11eeb50095ae571c645427b9a267bdee We don't unroll vector loops for MVE targets, but we miss the case when loops only contain intrinsic calls. So just move the logic a bit to catch this case. Differential Revision: https://reviews.llvm.org/D72440 2019-12-24T23:57:33+00:00 Fangrui Song maskray@google.com 2019-12-24T23:52:21+00:00 urn:sha1:502a77f125f43ffde57af34d3fd1b900248a91cd 2019-12-02T15:06:15+00:00 Roman Lebedev lebedev.ri@gmail.com 2019-12-02T14:34:55+00:00 urn:sha1:0f22e783a038b6983f0fe161eef6cf2add3a4156 rL341831 moved one-use check higher up, restricting a few folds that produced a single instruction from two instructions to the case where the inner instruction would go away. Original commit message: > InstCombine: move hasOneUse check to the top of foldICmpAddConstant > > There were two combines not covered by the check before now, > neither of which actually differed from normal in the benefit analysis. > > The most recent seems to be because it was just added at the top of the > function (naturally). The older is from way back in 2008 (r46687) > when we just didn't put those checks in so routinely, and has been > diligently maintained since. From the commit message alone, there doesn't seem to be a deeper motivation, deeper problem that was trying to solve, other than 'fixing the wrong one-use check'. As i have briefly discusses in IRC with Tim, the original motivation can no longer be recovered, too much time has passed. However i believe that the original fold was doing the right thing, we should be performing such a transformation even if the inner `add` will not go away - that will still unchain the comparison from `add`, it will no longer need to wait for `add` to compute. Doing so doesn't seem to break any particular idioms, as least as far as i can see. References https://bugs.llvm.org/show_bug.cgi?id=44100 2019-11-19T13:33:16+00:00 dfukalov daniil.fukalov@amd.com 2019-11-18T13:42:34+00:00 urn:sha1:6fd11b14f604914df4f777f4c7ff20dbbc50877b Summary: Most of IR instructions got better code size estimations after commit 47a5c36b. So default parameters values should be updated to improve inlining and unrolling for the target. Reviewers: rampitec, arsenm Reviewed By: rampitec Subscribers: kzhuravl, jvesely, wdng, nhaehnle, yaxunl, dstuttard, tpr, t-tye, hiraditya, zzheng, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D70391 2019-11-06T23:41:57+00:00 Philip Reames listmail@philipreames.com 2019-11-06T23:30:47+00:00 urn:sha1:8748be7750920b7bd669a47be72a81ee7f1d305c The basic idea of the transform is to convert variant loop exit conditions into invariant exit conditions by changing the iteration on which the exit is taken when we know that the trip count is unobservable. See the original patch which introduced the code for a more complete explanation. The individual parts of this have been reviewed, the result has been fuzzed, and then further analyzed by hand, but despite all of that, I will not be suprised to see breakage here. If you see problems, please don't hesitate to revert - though please do provide a test case. The most likely class of issues are latent SCEV bugs and without a reduced test case, I'll be essentially stuck on reducing them. (Note: A bunch of tests were opted out of the new transform to preserve coverage. That landed in a previous commit to simplify revert cycles if they turn out to be needed.) 2019-11-06T12:08:59+00:00 Roman Lebedev lebedev.ri@gmail.com 2019-11-06T11:57:49+00:00 urn:sha1:4fe94d033120da2000f1f31f0c54f3d95a159a53 Summary: I believe this bisects to https://reviews.llvm.org/D44983 (`[LoopUnroll] Only peel if a predicate becomes known in the loop body.`) While that revision did contain tests that showed arguably-subpar peeling for [in]equality predicates that [not] happen in the middle of the loop, it also disabled peeling for the *first* loop iteration, because latch would be canonicalized to [in]equality comparison.. That was intentional as per https://reviews.llvm.org/D44983#1059583. I'm not 100% sure that i'm using correct checks here, but this fix appears to be going in the right direction.. Let me know if i'm missing some checks here.. Fixes [[ https://bugs.llvm.org/show_bug.cgi?id=43840 | PR43840 ]]. Reviewers: fhahn, mkazantsev, efriedma Reviewed By: fhahn Subscribers: xbolva00, hiraditya, zzheng, llvm-commits, fhahn Tags: #llvm Differential Revision: https://reviews.llvm.org/D69617 2019-11-06T12:08:59+00:00 Roman Lebedev lebedev.ri@gmail.com 2019-11-06T11:56:59+00:00 urn:sha1:432a12c8037293bd1ff919a82f1d4412772ac534