Project Ortega BCM5719 LLVM https://git.raptorcs.com/git/bcm5719-llvm/atom?h=meklort-10.0.1 2019-12-25T00:05:15+00:00 2019-12-25T00:05:15+00:00 Fangrui Song maskray@google.com 2019-12-25T00:02:47+00:00 urn:sha1:eb16435b5e5df68d2410bbe4c08ef8ce8aa8b2f4 2019-11-12T15:17:04+00:00 Tom Weaver Tom.Weaver@Sony.com 2019-11-12T15:17:04+00:00 urn:sha1:41c3f76dcd0daeec60eddfcb56008a31ad6e8738 Reviewed By: aprantl, vsk Differential revision: https://reviews.llvm.org/D69943 2019-11-11T14:13:33+00:00 Tom Weaver Tom.Weaver@Sony.com 2019-11-11T14:13:33+00:00 urn:sha1:9f48a160dd3fd56314cfbbe74c56e09aaab11566 This reverts commit 1984a27db58e9053371ab6d6dc288c81c8a071ac. 2019-11-11T13:47:13+00:00 Tom Weaver Tom.Weaver@Sony.com 2019-11-11T13:47:13+00:00 urn:sha1:1984a27db58e9053371ab6d6dc288c81c8a071ac Reviewed By: aprantl, vsk Differential revision: https://reviews.llvm.org/D69943 2019-08-23T15:49:38+00:00 Cameron McInally cameron.mcinally@nyu.edu 2019-08-23T15:49:38+00:00 urn:sha1:688f3bc240d0886933e9bbe51167aabf05febe63 Differential Revision: https://reviews.llvm.org/D66612 llvm-svn: 369772 2019-08-10T13:17:54+00:00 Sanjay Patel spatel@rotateright.com 2019-08-10T13:17:54+00:00 urn:sha1:21c15ef38487ee91eea898dbe80bfc5f8d6c5252 This is an extension of a transform that tries to produce positive floating-point constants to improve canonicalization (and hopefully lead to more reassociation and CSE). The original patches were: D4904 D5363 (rL221721) But as the test diffs show, these were limited to basic patterns by walking from an instruction to its single user rather than recursively moving up the def-use sequence. No fast-math is required here because we're only rearranging implicit FP negations in intermediate ops. A motivating bug is: https://bugs.llvm.org/show_bug.cgi?id=32939 Differential Revision: https://reviews.llvm.org/D65954 llvm-svn: 368512 2019-08-08T13:08:17+00:00 Sanjay Patel spatel@rotateright.com 2019-08-08T13:08:17+00:00 urn:sha1:e1e749d86a61b98564b5cc439d8f737fba9008c8 llvm-svn: 368290 2019-08-01T23:30:32+00:00 Philip Reames listmail@philipreames.com 2019-08-01T23:30:32+00:00 urn:sha1:2264f96c2a3b5db3df1a33b15cc32f1797d47d2d llvm-svn: 367634 2019-07-31T16:53:22+00:00 Sanjay Patel spatel@rotateright.com 2019-07-31T16:53:22+00:00 urn:sha1:435cdecdf721e39ec3b732f0affde970eadac525 Reverse the canonicalization of fneg relative to fmul/fdiv. That makes it easier to implement the transforms (and possibly other fneg transforms) in 1 place because we can always start the pattern match from fneg (either the legacy binop or the new unop). There's a secondary practical benefit seen in PR21914 and PR42681: https://bugs.llvm.org/show_bug.cgi?id=21914 https://bugs.llvm.org/show_bug.cgi?id=42681 ...hoisting fneg rather than sinking seems to play nicer with LICM in IR (although this change may expose analysis holes in the other direction). 1. The instcombine test changes show the expected neutral IR diffs from reversing the order. 2. The reassociation tests show that we were missing an optimization opportunity to fold away fneg-of-fneg. My reading of IEEE-754 says that all of these transforms are allowed (regardless of binop/unop fneg version) because: "For all other operations [besides copy/abs/negate/copysign], this standard does not specify the sign bit of a NaN result." In all of these transforms, we always have some other binop (fadd/fsub/fmul/fdiv), so we are free to flip the sign bit of a potential intermediate NaN operand. (If that interpretation is wrong, then we must already have a bug in the existing transforms?) 3. The clang tests shouldn't exist as-is, but that's effectively a revert of rL367149 (the test broke with an extension of the pre-existing fneg canonicalization in rL367146). Differential Revision: https://reviews.llvm.org/D65399 llvm-svn: 367447 2019-06-24T21:36:09+00:00 Cameron McInally cameron.mcinally@nyu.edu 2019-06-24T21:36:09+00:00 urn:sha1:1e5116cbb3a00bc70d3fc6f0da24dcfcfbce4bf0 llvm-svn: 364232