Project Ortega BCM5719 LLVM https://git.raptorcs.com/git/bcm5719-llvm/atom?h=meklort-10.0.1 2019-06-06T19:21:23+00:00 2019-06-06T19:21:23+00:00 Craig Topper craig.topper@intel.com 2019-06-06T19:21:23+00:00 urn:sha1:ca541b20d0c885793c06bddf7966f3e93c03e32f Differential Revision: https://reviews.llvm.org/D62791 llvm-svn: 362737 2018-05-17T21:56:39+00:00 George Burgess IV george.burgess.iv@gmail.com 2018-05-17T21:56:39+00:00 urn:sha1:c6526176cf7c3678f9d7c96338f63365c4d5f8ab I don't believe the person who LGTMed this review has appropriate context on this code. I apologize if I'm wrong. llvm-svn: 332674 2018-05-17T20:23:33+00:00 David Bolvansky david.bolvansky@gmail.com 2018-05-17T20:23:33+00:00 urn:sha1:b1c59e3f30bf75255d8a1de14082a9e9fe806167 Summary: There was some unfinished work started for offset tracking in CFLGraph by the author of implementation of Andersen algorithm. This work was completed and support for field sensitivity was added to the core of Andersen algorithm. The performance results seem promising. SPEC2006 int_base score was increased by 1.1 % (I compared clang 6.0 with clang 6.0 with this patch). The avergae compile time was increased by +- 1 % according my measures with small and medium C/C++ projects (I did not tested it on the large projects with milions of lines of code) Reviewers: chandlerc, george.burgess.iv, rja Reviewed By: rja Subscribers: rja, llvm-commits Differential Revision: https://reviews.llvm.org/D46282 llvm-svn: 332657 2018-05-10T18:37:54+00:00 George Burgess IV george.burgess.iv@gmail.com 2018-05-10T18:37:54+00:00 urn:sha1:175400a801340a75c8fcd5c30924540ae84ad90f In general, it's difficult to poke the ConstantExpr code in CFLAA, since LLVM is so great at eagerly reducing ConstantExprs. :) Sadly, this only shows a functional difference from before the patch because CFLAA has some special logic around taking loads of non-pointers into account. Namely, with the broken select behavior, CFLAA will completely fail to take note of @g3. Since CFLAA doesn't have any record about @g3 when we do an alias query for @g3 and %a, it conservatively answers MayAlias. When we properly take @g3 into account with the new select logic, we get NoAlias for this query. I suspect that the aforementioned "special logic" isn't completely correct, but this test-case should prevent future wonky aliasing results from appearing for these flavors of ConstantExprs, so I think it's still worth having. llvm-svn: 332017 2017-05-31T02:35:26+00:00 George Burgess IV george.burgess.iv@gmail.com 2017-05-31T02:35:26+00:00 urn:sha1:0a7b9890363e7870cfcc938f8e2117d2a938bfe1 Thanks to Galina Kistanova for finding the missing break! When trying to make a test for this, I realized our logic for handling extractvalue/insertvalue/... is somewhat broken. This makes constructing a test-case for this missing break nontrivial. llvm-svn: 304275 2016-12-11T20:07:15+00:00 Sanjoy Das sanjoy@playingwithpointers.com 2016-12-11T20:07:15+00:00 urn:sha1:3336f681e3f548e082d363b848edaeb3e0fcb644 Summary: This change adds some verification in the IR verifier around struct path TBAA metadata. Other than some basic sanity checks (e.g. we get constant integers where we expect constant integers), this checks: - That by the time an struct access tuple `(base-type, offset)` is "reduced" to a scalar base type, the offset is `0`. For instance, in C++ you can't start from, say `("struct-a", 16)`, and end up with `("int", 4)` -- by the time the base type is `"int"`, the offset better be zero. In particular, a variant of this invariant is needed for `llvm::getMostGenericTBAA` to be correct. - That there are no cycles in a struct path. - That struct type nodes have their offsets listed in an ascending order. - That when generating the struct access path, you eventually reach the access type listed in the tbaa tag node. Reviewers: dexonsmith, chandlerc, reames, mehdi_amini, manmanren Subscribers: mcrosier, llvm-commits Differential Revision: https://reviews.llvm.org/D26438 llvm-svn: 289402 2016-08-01T18:47:28+00:00 George Burgess IV george.burgess.iv@gmail.com 2016-08-01T18:47:28+00:00 urn:sha1:5f0e76dca64c24ac9b97536d75b8438b86a7b8db As it turns out, modref queries are broken with CFLAA. Specifically, the data source we were using for determining modref behaviors explicitly ignores operations on non-pointer values. So, it wouldn't note e.g. storing an i32 to an i32* (or loading an i64 from an i64*). It also ignores external function calls, rather than acting conservatively for them. (N.B. These operations, where necessary, *are* tracked by CFLAA; we just use a different mechanism to do so. Said mechanism is relatively imprecise, so it's unlikely that we can provide reasonably good modref answers with it as implemented.) Patch by Jia Chen. Differential Revision: https://reviews.llvm.org/D22978 llvm-svn: 277366 2016-07-27T23:07:07+00:00 George Burgess IV george.burgess.iv@gmail.com 2016-07-27T23:07:07+00:00 urn:sha1:dbd35c44d4fe5e4f092ecdd2d2ca1c2205f7d2c1 This patch lets CFLAnders respond to mod-ref queries. It also includes a small bugfix to CFLSteens. Patch by Jia Chen. Differential Revision: https://reviews.llvm.org/D22823 llvm-svn: 276939 2016-07-19T20:56:41+00:00 George Burgess IV george.burgess.iv@gmail.com 2016-07-19T20:56:41+00:00 urn:sha1:8b85321bae0303c456e256cbb910ebe753398e60 Dishonesty noted by Jia Chen. llvm-svn: 276028 2016-07-19T20:47:15+00:00 George Burgess IV george.burgess.iv@gmail.com 2016-07-19T20:47:15+00:00 urn:sha1:3b059841ff4b9660b0f1696d1aaf8f194fc42275 This patch adds function summary support to CFLAnders. It also comes with a lot of tests! Woohoo! Patch by Jia Chen. Differential Revision: https://reviews.llvm.org/D22450 llvm-svn: 276026