{"push_id":2733431269,"size":34,"distinct_size":1,"ref":"refs/heads/atomic_expand","head":"3ea926e579e201c25f89dfb7c6d568da193f108c","before":"af199df4167fca2323bd48ece293c898886e62c1","commits":[{"sha":"e601e5fe08b6a9c73c79efb1f2f476e87f56f163","author":{"name":"Peter Collingbourne","email":"4b8373d016f277527198385ba72fda0feb5da015@pcc.me.uk"},"message":"Rename __asan_gen_* symbols to ___asan_gen_*.\n\nThis prevents gold from printing a warning when trying to export\nthese symbols via the asan dynamic list after ThinLTO promotes them\nfrom private symbols to external symbols with hidden visibility.\n\nDifferential Revision: https://reviews.llvm.org/D49498\n\ngit-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@337428 91177308-0d34-0410-b5e6-96231b3b80d8","distinct":false,"url":"https://api.github.com/repos/aheejin/llvm/commits/e601e5fe08b6a9c73c79efb1f2f476e87f56f163"},{"sha":"62b518b75a780a3bc75982cbe54b0e7bc262aa6e","author":{"name":"Max Kazantsev","email":"126b382300ba84ca1bf6db52c0b4ca707d2309ed@azul.com"},"message":"[SCEV] Fix buggy behavior in getAddExpr with truncs\n\nSCEV tries to constant-fold arguments of trunc operands in SCEVAddExpr, and when it does\nthat, it passes wrong flags into the recursion. It is only valid to pass flags that are proved for\nnarrow type into a computation in wider type if we can prove that trunc instruction doesn't\nactually change the value. If it did lose some meaningful bits, we may end up proving wrong\nno-wrap flags for sum of arguments of trunc.\n\nIn the provided test we end up with `nuw` where it shouldn't be because of this bug.\n\nThe solution is to conservatively pass `SCEV::FlagAnyWrap` which is always a valid thing to do.\n\nReviewed By: sanjoy\nDifferential Revision: https://reviews.llvm.org/D49471\n\n\ngit-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@337435 91177308-0d34-0410-b5e6-96231b3b80d8","distinct":false,"url":"https://api.github.com/repos/aheejin/llvm/commits/62b518b75a780a3bc75982cbe54b0e7bc262aa6e"},{"sha":"ef2fcbd30cfc86cd73362921e624de9d0ded150a","author":{"name":"Simon Pilgrim","email":"af4b1a06dcc93e086b35435d5654eb2aff59399a@redking.me.uk"},"message":"Fix spelling mistake in comments. NFCI.\n\ngit-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@337442 91177308-0d34-0410-b5e6-96231b3b80d8","distinct":false,"url":"https://api.github.com/repos/aheejin/llvm/commits/ef2fcbd30cfc86cd73362921e624de9d0ded150a"},{"sha":"cfc3a3cba210f9971270707f81c03b8dab2163c3","author":{"name":"Serge Guelton","email":"acd00f5c83830e99c52df96c5ab43189d3c06b8b@quarkslab.com"},"message":"Use std::reference_wrapper instead of llvm::ReferenceStorage\n\nReviewed By: Bigcheese\nDifferential Revision: https://reviews.llvm.org/D49298\n\n\ngit-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@337444 91177308-0d34-0410-b5e6-96231b3b80d8","distinct":false,"url":"https://api.github.com/repos/aheejin/llvm/commits/cfc3a3cba210f9971270707f81c03b8dab2163c3"},{"sha":"3a2e78e840c0bd281fbce66f454b771e46e863f9","author":{"name":"Simon Pilgrim","email":"af4b1a06dcc93e086b35435d5654eb2aff59399a@redking.me.uk"},"message":"[DAGCombiner] Add rotate-extract tests\n\nAdd new tests from D47681 to current codegen. Also added i686 codegen tests.\n\ngit-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@337445 91177308-0d34-0410-b5e6-96231b3b80d8","distinct":false,"url":"https://api.github.com/repos/aheejin/llvm/commits/3a2e78e840c0bd281fbce66f454b771e46e863f9"},{"sha":"d13704d44f36e28c02ff6ca1e8849760fa020ead","author":{"name":"Chandler Carruth","email":"420c9fb3407b8e11ac322a0e7703f7b1f526df04@gmail.com"},"message":"[x86/SLH] Major refactoring of SLH implementaiton. There are two big\nchanges that are intertwined here:\n\n1) Extracting the tracing of predicate state through the CFG to its own\n   function.\n2) Creating a struct to manage the predicate state used throughout the\n   pass.\n\nDoing #1 necessitates and motivates the particular approach for #2 as\nnow the predicate management is spread across different functions\nfocused on different aspects of it. A number of simplifications then\nfell out as a direct consequence.\n\nI went with an Optional to make it more natural to construct the\nMachineSSAUpdater object.\n\nThis is probably the single largest outstanding refactoring step I have.\nThings get a bit more surgical from here. My current goal, beyond\ngenerally making this maintainable long-term, is to implement several\nimprovements to how we do interprocedural tracking of predicate state.\nBut I don't want to do that until the predicate state management and\ntracing is in reasonably clear state.\n\nDifferential Revision: https://reviews.llvm.org/D49427\n\ngit-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@337446 91177308-0d34-0410-b5e6-96231b3b80d8","distinct":false,"url":"https://api.github.com/repos/aheejin/llvm/commits/d13704d44f36e28c02ff6ca1e8849760fa020ead"},{"sha":"91823932bda4a288a66ef1ba157dbf2e644bfb60","author":{"name":"David Green","email":"4503caa52df5afa1c818a4a776e14b0cb7e5dc0c@arm.com"},"message":"[UnJ] Document unroll and jam pass and loop metadata\n\nAdd some quick words for unroll and jam to the list of passes and add\nunroll_and_jam metadata to the language ref.\n\nDifferential Revision: https://reviews.llvm.org/D49349\n\n\n\ngit-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@337448 91177308-0d34-0410-b5e6-96231b3b80d8","distinct":false,"url":"https://api.github.com/repos/aheejin/llvm/commits/91823932bda4a288a66ef1ba157dbf2e644bfb60"},{"sha":"95f104ac2d556a79c53a758293710b5fb3eb5227","author":{"name":"Tim Northover","email":"26294bcb01cdc361afe06a2787bab8d16e97ede5@apple.com"},"message":"ARM: switch armv7em MachO triple to hard-float defaults and libcalls.\n\nWe were emitting incorrect calls to libm functions that LLVM had decided it\nknew about because the default is soft-float.\n\nRecommitted without breaking ELF this time.\n\ngit-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@337450 91177308-0d34-0410-b5e6-96231b3b80d8","distinct":false,"url":"https://api.github.com/repos/aheejin/llvm/commits/95f104ac2d556a79c53a758293710b5fb3eb5227"},{"sha":"629edfbb7a4c544a02175f801499137833ea6cac","author":{"name":"Anastasis Grammenos","email":"334d12463e78182a2a1c7b35872eb085b7e67334@gmail.com"},"message":"[Docs] Testing Debug Info Preservation in Optimizations\n\nDifferential Revision: https://reviews.llvm.org/D49053\n\ngit-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@337457 91177308-0d34-0410-b5e6-96231b3b80d8","distinct":false,"url":"https://api.github.com/repos/aheejin/llvm/commits/629edfbb7a4c544a02175f801499137833ea6cac"},{"sha":"2a478d43e1f4f6ee0a8a60ded4bb65d655ad418d","author":{"name":"Teresa Johnson","email":"25199b71953b1ae8370658789972819bf995cdd9@google.com"},"message":"[ThinLTO] Enable ThinLTO WholeProgramDevirt and LowerTypeTests in new PM\n\nSummary:\nEnable these passes for CFI and WPD in ThinLTO and LTO with the new pass\nmanager. Add a couple of tests for both PMs based on the clang tests\ntools/clang/test/CodeGen/thinlto-distributed-cfi*.ll, but just test\nthrough llvm-lto2 and not with distributed ThinLTO.\n\nReviewers: pcc\n\nSubscribers: mehdi_amini, inglorion, eraman, steven_wu, dexonsmith, llvm-commits\n\nDifferential Revision: https://reviews.llvm.org/D49429\n\ngit-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@337461 91177308-0d34-0410-b5e6-96231b3b80d8","distinct":false,"url":"https://api.github.com/repos/aheejin/llvm/commits/2a478d43e1f4f6ee0a8a60ded4bb65d655ad418d"},{"sha":"efd8832ecbaf9e201e2ca11057f24b9fe6969714","author":{"name":"George Rimar","email":"2fd69a2f24b0bf277ee2823ffd2cdc788ba995f8@accesssoftek.com"},"message":"[llvm-readobj] - Do not report invalid amount of sections.\n\nWhen output style is GNU and amount of sections is >= SHN_LORESERVE,\nllvm-readobj reports zero number of sections instead of actual value.\n\nThe patch fixes that.\n\nDifferential revision: https://reviews.llvm.org/D49544\n\ngit-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@337462 91177308-0d34-0410-b5e6-96231b3b80d8","distinct":false,"url":"https://api.github.com/repos/aheejin/llvm/commits/efd8832ecbaf9e201e2ca11057f24b9fe6969714"},{"sha":"19ad9309e1e052c90ac620413ae752cbaf6d91d8","author":{"name":"Simon Pilgrim","email":"af4b1a06dcc93e086b35435d5654eb2aff59399a@redking.me.uk"},"message":"[X86][SSE] Add FPEXT vXf32 - vXf64 tests\n\nSome basic subvector special cases based on PR36761\n\ngit-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@337464 91177308-0d34-0410-b5e6-96231b3b80d8","distinct":false,"url":"https://api.github.com/repos/aheejin/llvm/commits/19ad9309e1e052c90ac620413ae752cbaf6d91d8"},{"sha":"3b09b9e80ea336869ce855baa4c11b5cd762aa44","author":{"name":"Andrea Di Biagio","email":"477cf5b24d5c0cb561469a6faea86f0cd78ed1ab@sn.scee.net"},"message":"[X86][BtVer2] correctly model the latency/throughput of LEA instructions.\n\nThis patch fixes the latency/throughput of LEA instructions in the BtVer2\nscheduling model.\n\nOn Jaguar, A 3-operands LEA has a latency of 2cy, and a reciprocal throughput of\n1. That is because it uses one cycle of SAGU followed by 1cy of ALU1.  An LEA\nwith a \"Scale\" operand is also slow, and it has the same latency profile as the\n3-operands LEA. An LEA16r has a latency of 3cy, and a throughput of 0.5 (i.e.\nRThrouhgput of 2.0).\n\nThis patch adds a new TIIPredicate named IsThreeOperandsLEAFn to X86Schedule.td.\nThe tablegen backend (for instruction-info) expands that definition into this\n(file X86GenInstrInfo.inc):\n```\nstatic bool isThreeOperandsLEA(const MachineInstr &MI) {\n  return (\n    (\n      MI.getOpcode() == X86::LEA32r\n      || MI.getOpcode() == X86::LEA64r\n      || MI.getOpcode() == X86::LEA64_32r\n      || MI.getOpcode() == X86::LEA16r\n    )\n    && MI.getOperand(1).isReg()\n    && MI.getOperand(1).getReg() != 0\n    && MI.getOperand(3).isReg()\n    && MI.getOperand(3).getReg() != 0\n    && (\n      (\n        MI.getOperand(4).isImm()\n        && MI.getOperand(4).getImm() != 0\n      )\n      || (MI.getOperand(4).isGlobal())\n    )\n  );\n}\n```\n\nA similar method is generated in the X86_MC namespace, and included into\nX86MCTargetDesc.cpp (the declaration lives in X86MCTargetDesc.h).\n\nBack to the BtVer2 scheduling model:\nA new scheduling predicate named JSlowLEAPredicate now checks if either the\ninstruction is a three-operands LEA, or it is an LEA with a Scale value\ndifferent than 1.\nA variant scheduling class uses that new predicate to correctly select the\nappropriate latency profile.\n\nDifferential Revision: https://reviews.llvm.org/D49436\n\n\ngit-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@337469 91177308-0d34-0410-b5e6-96231b3b80d8","distinct":false,"url":"https://api.github.com/repos/aheejin/llvm/commits/3b09b9e80ea336869ce855baa4c11b5cd762aa44"},{"sha":"ae72a8c5708fafd6d47b5e23cd10a1f844d00cd4","author":{"name":"Farhana Aleen","email":"6f3c4fc3a36a36c78c831ff1ac5f3ce9ef337418@gmail.com"},"message":"[LoadStoreVectorizer] Use getMinusScev() to compute the distance between two pointers.\n\nSummary: Currently, isConsecutiveAccess() detects two pointers(PtrA and PtrB) as consecutive by\n         comparing PtrB with BaseDelta+PtrA. This works when both pointers are factorized or\n         both of them are not factorized. But isConsecutiveAccess() fails if one of the\n         pointers is factorized but the other one is not.\n\n         Here is an example:\n         PtrA = 4 * (A + B)\n         PtrB = 4 + 4A + 4B\n\n         This patch uses getMinusSCEV() to compute the distance between two pointers.\n         getMinusSCEV() allows combining the expressions and computing the simplified distance.\n\nAuthor: FarhanaAleen\n\nReviewed By: rampitec\n\nDifferential Revision: https://reviews.llvm.org/D49516\n\ngit-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@337471 91177308-0d34-0410-b5e6-96231b3b80d8","distinct":false,"url":"https://api.github.com/repos/aheejin/llvm/commits/ae72a8c5708fafd6d47b5e23cd10a1f844d00cd4"},{"sha":"5b81b48075a69e9beda4eb869dc8eb0e9d09a156","author":{"name":"Matt Morehouse","email":"ea42b74972c358d17537b0589eea23cae0a6b60b@google.com"},"message":"[libFuzzer] Update documentation regarding MSan.\n\nSummary: -fsanitize=fuzzer,memory now works out-of-the-box.\n\nReviewers: kcc\n\nReviewed By: kcc\n\nSubscribers: llvm-commits\n\nDifferential Revision: https://reviews.llvm.org/D49441\n\ngit-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@337476 91177308-0d34-0410-b5e6-96231b3b80d8","distinct":false,"url":"https://api.github.com/repos/aheejin/llvm/commits/5b81b48075a69e9beda4eb869dc8eb0e9d09a156"},{"sha":"3bb52cad65ae408d80b24051fc30fdbb0c5fcb10","author":{"name":"Krzysztof Parzyszek","email":"c75c6ffbe1757b9a0c4a980ebbd301c4f55ecd30@codeaurora.org"},"message":"[APInt] Keep the original bit width in quotient and remainder\n\nSome trivial cases in udivrem were handled by directly assigning 0 or 1\nto APInt objects. This would set the bit width to 1, instead of the bit\nwidth of the inputs. A potentially undesirable side effect of that is\nthat with the bit width of 1, 1 equals -1.\n\nDifferential Revision: https://reviews.llvm.org/D49554\n\n\ngit-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@337478 91177308-0d34-0410-b5e6-96231b3b80d8","distinct":false,"url":"https://api.github.com/repos/aheejin/llvm/commits/3bb52cad65ae408d80b24051fc30fdbb0c5fcb10"},{"sha":"a02ad35dfa959d5c50a5d0008b010e5fb0c5cbe8","author":{"name":"Mandeep Singh Grang","email":"414d85aef57abf2205af5f15419474bebe846edf@codeaurora.org"},"message":"[OpenEmbedded] Add a unittest for aarch64-oe-linux\n\nSummary: Added a unittest for aarch64-oe-linux which was missed in D48861.\n\nReviewers: compnerd, rengolin, javed.absar\n\nReviewed By: compnerd\n\nSubscribers: kristof.beyls, dexonsmith, llvm-commits\n\nDifferential Revision: https://reviews.llvm.org/D49314\n\ngit-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@337479 91177308-0d34-0410-b5e6-96231b3b80d8","distinct":false,"url":"https://api.github.com/repos/aheejin/llvm/commits/a02ad35dfa959d5c50a5d0008b010e5fb0c5cbe8"},{"sha":"6e5028379153b9a0e662f6420f111e2d879ab5f6","author":{"name":"Shoaib Meenai","email":"32ebf52f3161ede99d2feb19726ba0d4dc358548@fb.com"},"message":"[Analysis] Fix typo in assert. NFC\n\nTest commit to see if my mailing list woes have been resolved.\n\ngit-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@337485 91177308-0d34-0410-b5e6-96231b3b80d8","distinct":false,"url":"https://api.github.com/repos/aheejin/llvm/commits/6e5028379153b9a0e662f6420f111e2d879ab5f6"},{"sha":"f9fb677cc2434e62c164c1322dbe7eacb47617f3","author":{"name":"Stefan Pintilie","email":"21b238a089085d3bb2c64707eeca2dc9cb7c11cb@ca.ibm.com"},"message":"[Power9] Code Cleanup - Remove needsAggressiveScheduling()\n\nAs we already return true from needsAggressiveScheduling() for the most recent\nhardware it would be cleaner to just return true for all PowerPC hardware.\n\nDifferential Revision: https://reviews.llvm.org/D48663\n\ngit-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@337488 91177308-0d34-0410-b5e6-96231b3b80d8","distinct":false,"url":"https://api.github.com/repos/aheejin/llvm/commits/f9fb677cc2434e62c164c1322dbe7eacb47617f3"},{"sha":"b2f9f92413fa4c9669f5f49716745c5f90d3fd61","author":{"name":"Roman Tereshin","email":"9f5605aa7534078ac143ef848e29fbf210f38d66@apple.com"},"message":"[LSV] Refactoring + supporting bitcasts to a type of different size\n\nThis is mostly a preparation work for adding a limited support for\nselect instructions. It proved to be difficult to do due to size and\nirregularity of Vectorizer::isConsecutiveAccess, this is fixed here I\nbelieve.\n\nIt also turned out that these changes make it simpler to finish one of\nthe TODOs and fix a number of other small issues, namely:\n\n1. Looking through bitcasts to a type of a different size (requires\ncareful tracking of the original load/store size and some math\nconverting sizes in bytes to expected differences in indices of GEPs).\n\n2. Reusing partial analysis of pointers done by first attempt in proving\nthem consecutive instead of starting from scratch. This added limited\nsupport for nested GEPs co-existing with difficult sext/zext\ninstructions. This also required a careful handling of negative\ndifferences between constant parts of offsets.\n\n3. Handing a case where the first pointer index is not an add, but\nsomething else (a function parameter for instance).\n\nI observe an increased number of successful vectorizations on a large\nset of shader programs. Only few shaders are affected, but those that\nare affected sport >5% less loads and stores than before the patch.\n\nReviewed By: rampitec\n\nDifferential-Revision: https://reviews.llvm.org/D49342\n\ngit-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@337489 91177308-0d34-0410-b5e6-96231b3b80d8","distinct":false,"url":"https://api.github.com/repos/aheejin/llvm/commits/b2f9f92413fa4c9669f5f49716745c5f90d3fd61"}]}
{"actor":{"display_login":"aheejin"}}