{"push_id":656023574,"size":49,"distinct_size":49,"ref":"refs/heads/master","head":"4d5e059cdb3cdc08d905a6ba0f270fe478a88c02","before":"0358a25e786b67b783063be8c8c2c8dc285f2e8c","commits":[{"sha":"982f60be4432d66d819b6018ebbdb19379f29e72","author":{"email":"226409dbd0f8f7302b911c342b723f8b80eeb87d@linux.vnet.ibm.com","name":"Bill Schmidt"},"message":"[PPC64LE] Adjust vector splats during VSX swap optimization\n\nThe initial code drop for VSX swap optimization permitted the\noptimization only when all operations in a web of related computation\nare lane-insensitive.  For some lane-sensitive operations, we can\nstill permit the optimization provided that we make adjustments to\nthose operations.  This patch adds special handling for vector splats\nso that their presence doesn't kill the optimization.\n\nVector splats are lane-sensitive since they identify by number a\nvector element to be used as the source of a splat.  When swap\noptimizations take place, the desired vector element will move to the\nopposite doubleword of the quadword vector.  We thus replace the index\nI by (I + N/2) % N, where N is the number of elements in the vector.\n\nA new test case is added to test that swap optimization succeeds when\nvector splats are present, and that the proper input element is used\nas the source of the splat.\n\nAn ancillary change removes SH_BUILDVEC as one of the kinds of special\nhandling that may be required by VSX swap optimization.  From\nexperience with GCC, I had expected to need some modifications for\nvector build operations, but I did not find that to be the case.\n\n\ngit-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@236606 91177308-0d34-0410-b5e6-96231b3b80d8","distinct":true,"url":"https://api.github.com/repos/J-Liu/llvm/commits/982f60be4432d66d819b6018ebbdb19379f29e72"},{"sha":"99413f0d403eaaf0be6ab875a6f638a6067fd97f","author":{"email":"607a4aeae37c8a26eb86f95c436fb926ad94d55c@apple.com","name":"Pete Cooper"},"message":"[ARM] Fast-Isel was incorrectly selecting <2 x double> adds.\n\nWith neon enabled, we reach SelectBinaryFPOp and are able to get registers for a <2 x double> add.\n\nHowever, we shouldn't actually attempt arithmetic on it as ARMIselLowering says \"v2f64 is legal so that QR subregs can be extracted as f64 elements, but neither Neon nor VFP support any arithmetic operations on it.\"\n\nThis commit disables SelectBinaryFPOp for any vector types.  There's already a FIXME to try handle neon.  Doing so would require fixing this conditional which isn't safe for vectors 'VT == MVT::f64 || VT == MVT::i64'\n\ngit-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@236609 91177308-0d34-0410-b5e6-96231b3b80d8","distinct":true,"url":"https://api.github.com/repos/J-Liu/llvm/commits/99413f0d403eaaf0be6ab875a6f638a6067fd97f"},{"sha":"53043147021689c80c160e9bb0f01ef82ebf7a8e","author":{"email":"04e070ef469e06d5be3276f222c4884739e89017@gmail.com","name":"Pawel Bylica"},"message":"Readd the regression test from r236584. Calling convention fixed to linux.\n\ngit-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@236610 91177308-0d34-0410-b5e6-96231b3b80d8","distinct":true,"url":"https://api.github.com/repos/J-Liu/llvm/commits/53043147021689c80c160e9bb0f01ef82ebf7a8e"},{"sha":"683cf0f88fec1c9a6eb0bf2b53376e468497e663","author":{"email":"3cf7ba45f835c4cf8b5fe7d6a48fa95fd7df4df7@google.com","name":"Derek Schuff"},"message":"Add bitcode test to verify functions can be materialized out of order.\n\nSummary:\nAdds test to check that when getLazyBitcodeModule is called:\n1) Functions are not materailzed by default.\n2) Only the requested function gets materialized (if no block addresses\n   are used).\n\nReviewers: jvoung, rafael\n\nReviewed By: rafael\n\nSubscribers: llvm-commits\n\nDifferential Revision: http://reviews.llvm.org/D8907\n\ngit-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@236611 91177308-0d34-0410-b5e6-96231b3b80d8","distinct":true,"url":"https://api.github.com/repos/J-Liu/llvm/commits/683cf0f88fec1c9a6eb0bf2b53376e468497e663"},{"sha":"530a574a9dc6de13fe2bab31a461ba6bdb2a4c54","author":{"email":"788c14eeffa2067e120409a238fa186a04f20a10@amd.com","name":"Matt Arsenault"},"message":"Add ChangeTo* to MachineOperand for symbols\n\ngit-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@236612 91177308-0d34-0410-b5e6-96231b3b80d8","distinct":true,"url":"https://api.github.com/repos/J-Liu/llvm/commits/530a574a9dc6de13fe2bab31a461ba6bdb2a4c54"},{"sha":"cac51be31f152b736beda01b557546e02a92ee6c","author":{"email":"c7a93d10b09f6e991164d9c1ce8125070c3e456b@google.com","name":"Wei Mi"},"message":"[X86] Disable loop unrolling in loop vectorization pass when VF is 1.\n\nThe patch disabled unrolling in loop vectorization pass when VF==1 on x86 architecture,\nby setting MaxInterleaveFactor to 1. Unrolling in loop vectorization pass may introduce\nthe cost of overflow check, memory boundary check and extra prologue/epilogue code when\nregular unroller will unroll the loop another time. Disable it when VF==1 remove the\nunnecessary cost on x86. The same can be done for other platforms after verifying\ninterleaving/memory bound checking to be not perf critical on those platforms.\n\nDifferential Revision: http://reviews.llvm.org/D9515\n\n\ngit-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@236613 91177308-0d34-0410-b5e6-96231b3b80d8","distinct":true,"url":"https://api.github.com/repos/J-Liu/llvm/commits/cac51be31f152b736beda01b557546e02a92ee6c"},{"sha":"5a6ea245b00004cc0e44ce3afee16322a0a34509","author":{"email":"d72748a98fd8b476107003df407128e166d060ac@playingwithpointers.com","name":"Sanjoy Das"},"message":"Add missing dereferenceable_or_null getters\n\nSummary: Add missing dereferenceable_or_null getters required for\nhttp://reviews.llvm.org/D9253 change. Separated from the D9253 review.\n\nPatch by Artur Pilipenko!\n\nReviewers: sanjoy\n\nReviewed By: sanjoy\n\nSubscribers: llvm-commits\n\nDifferential Revision: http://reviews.llvm.org/D9499\n\ngit-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@236615 91177308-0d34-0410-b5e6-96231b3b80d8","distinct":true,"url":"https://api.github.com/repos/J-Liu/llvm/commits/5a6ea245b00004cc0e44ce3afee16322a0a34509"},{"sha":"26e46f2283043c805e3682f3009f67fbaaf5706c","author":{"email":"1f7432263446ac4f226b3f79c32d2744a3aa227f@google.com","name":"Diego Novillo"},"message":"Allow 0-weight branches in BranchProbabilityInfo.\n\nSummary:\nWhen computing branch weights in BPI, we used to disallow branches with\nweight 0. This is a minor nuisance, because a branch with weight 0 is\ndifferent to \"don't have information\". In the context of\ninstrumentation, it may mean \"never executed\", in the context of\nsampling, it means \"never or seldom executed\".\n\nIn allowing 0 weight branches, I ran into issues with the switch\nexpansion code in selection DAG. It is currently hardwired to not handle\nbranches with weight 0. To maintain the current behaviour, I changed it\nto use 1 when it finds 0, but perhaps the algorithm needs changes to\ntolerate branches with weight zero.\n\nReviewers: hansw\n\nSubscribers: llvm-commits\n\nDifferential Revision: http://reviews.llvm.org/D9533\n\ngit-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@236617 91177308-0d34-0410-b5e6-96231b3b80d8","distinct":true,"url":"https://api.github.com/repos/J-Liu/llvm/commits/26e46f2283043c805e3682f3009f67fbaaf5706c"},{"sha":"94c39f691453f19a60049176b1026f05871d3895","author":{"email":"d72748a98fd8b476107003df407128e166d060ac@playingwithpointers.com","name":"Sanjoy Das"},"message":"[SelectionDAG] Delete SelectionDAGBuilder::removeValue. NFC.\n\nSelectionDAGBuilder::removeValue is dead now, after rL236563.\n\ngit-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@236618 91177308-0d34-0410-b5e6-96231b3b80d8","distinct":true,"url":"https://api.github.com/repos/J-Liu/llvm/commits/94c39f691453f19a60049176b1026f05871d3895"},{"sha":"00157f3ae8298ae81c017abc65760fb3fa604f8a","author":{"email":"d7a6b5668afca32909ec82de7d490acab5faf1b8@kleckner.net","name":"Reid Kleckner"},"message":"[WinEH] Improve fatal error message about failed demotion\n\ngit-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@236626 91177308-0d34-0410-b5e6-96231b3b80d8","distinct":true,"url":"https://api.github.com/repos/J-Liu/llvm/commits/00157f3ae8298ae81c017abc65760fb3fa604f8a"},{"sha":"4e21d7aff9187de570062ae6e58f42205466b93b","author":{"email":"e162507022e397d7dd9485bf3b905d4b7b9c6661@gmail.com","name":"Ismail Pazarbasi"},"message":"Implement `createSanitizerCtor`, common helper function for all sanitizers\n\nSummary:\nThis helper function creates a ctor function, which calls sanitizer's\ninit function with given arguments. This constructor is then expected\nto be added to module's ctors. The patch helps unifying how sanitizer\nconstructor functions are created, and how init functions are called\nacross all sanitizers.\n\nReviewers: kcc, samsonov\n\nSubscribers: llvm-commits\n\nDifferential Revision: http://reviews.llvm.org/D8777\n\ngit-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@236627 91177308-0d34-0410-b5e6-96231b3b80d8","distinct":true,"url":"https://api.github.com/repos/J-Liu/llvm/commits/4e21d7aff9187de570062ae6e58f42205466b93b"},{"sha":"7838051bda3ee8b95c73c6d5e1a97ea3570684f1","author":{"email":"20d921fc546146872790792fbd1b5fc4bad0eb3d@apple.com","name":"Duncan P. N. Exon Smith"},"message":"DwarfDebug: Emit number of bytes in .debug_loc entry directly\n\nEmit the number of bytes in a `.debug_loc` entry directly.  The old code\ncreated temp labels (expensive), emitted the difference between them,\nand then emitted one on each side of the relevant bytes.\n\n(I'm looking at `llc` memory usage on `verify-uselistorder.lto.opt.bc`\n(the optimized version of ld64's `-save-temps` when linking the\n`verify-uselistorder` executable in an LTO bootstrap).  I've hacked\n`MCContext::Allocate()` to just call `malloc()` instead of using the\n`BumpPtrAllocator` so that the heap profile is easier to read.  As far\nas peak memory is concerned, `MCContext::Allocate()` is equivalent to a\nleak, since it only gets freed at process teardown.\n\nIn my heap profile, this patch drops memory usage of\n`DwarfDebug::emitDebugLoc()` from 132.56 MB (11.4%) down to 29.86 MB\n(2.7%) at peak memory.  Some of that must be noise from `SmallVector`\n(or other) allocations -- peak memory only dropped from 1160 MB down to\n1100 MB -- but this nevertheless shaves 5% off the top.)\n\ngit-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@236629 91177308-0d34-0410-b5e6-96231b3b80d8","distinct":true,"url":"https://api.github.com/repos/J-Liu/llvm/commits/7838051bda3ee8b95c73c6d5e1a97ea3570684f1"},{"sha":"84b8c10729836ab3247bfa256101ba846eaefd92","author":{"email":"26294bcb01cdc361afe06a2787bab8d16e97ede5@apple.com","name":"Tim Northover"},"message":"CodeGen: move over-zealous assert into actual if statement.\n\nIt's quite possible to encounter an insertvalue instruction that's more deeply\nnested than the value we're looking for, but when that happens we really\nmustn't compare beyond the end of the index array.\n\nSince I couldn't see any guarantees about what comparisons std::equal makes, we\nprobably need to directly check the size beforehand. In practice, I suspect\nmost std::equal implementations would probably bail early, which would be OK.\nBut just in case...\n\nrdar://20834485\n\ngit-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@236635 91177308-0d34-0410-b5e6-96231b3b80d8","distinct":true,"url":"https://api.github.com/repos/J-Liu/llvm/commits/84b8c10729836ab3247bfa256101ba846eaefd92"},{"sha":"a414ba7844de23e51689fc741eb58190a6342627","author":{"email":"20d921fc546146872790792fbd1b5fc4bad0eb3d@apple.com","name":"Duncan P. N. Exon Smith"},"message":"MC: Skip names of temporary symbols in object streamer\n\nDon't create names for temporary symbols when using an object streamer.\nThe names never make it to the output anyway.  From the starting point\nof r236629, my heap profile says this drops peak memory usage from 1100\nMB to 1058 MB for CodeGen of `verify-uselistorder`, a savings of almost\n4% on peak memory, and removes `StringMap<bool, BumpPtrAllocator...>`\nfrom the profile entirely.\n\n(I'm looking at `llc` memory usage on `verify-uselistorder.lto.opt.bc`;\nsee r236629 for details.)\n\ngit-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@236642 91177308-0d34-0410-b5e6-96231b3b80d8","distinct":true,"url":"https://api.github.com/repos/J-Liu/llvm/commits/a414ba7844de23e51689fc741eb58190a6342627"},{"sha":"d71e55b97fe93f6186a5be79e788634fe9c27e55","author":{"email":"f6f4ad3113690f7f576bf13e93271274145387d1@gmail.com","name":"Alexey Samsonov"},"message":"[SanitizerCoverage] Fix a couple of typos. NFC.\n\ngit-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@236643 91177308-0d34-0410-b5e6-96231b3b80d8","distinct":true,"url":"https://api.github.com/repos/J-Liu/llvm/commits/d71e55b97fe93f6186a5be79e788634fe9c27e55"},{"sha":"0040d179d275b304591817b6d2058d96460d7ed9","author":{"email":"607a4aeae37c8a26eb86f95c436fb926ad94d55c@apple.com","name":"Pete Cooper"},"message":"[x86] Fix register class of folded load index reg.\n\nWhen folding a load in to another instruction, we need to fix the class of the index register\nOtherwise, it could be something like GR64 not GR64_NOSP and would fail the machine verifier.\n\ngit-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@236644 91177308-0d34-0410-b5e6-96231b3b80d8","distinct":true,"url":"https://api.github.com/repos/J-Liu/llvm/commits/0040d179d275b304591817b6d2058d96460d7ed9"},{"sha":"537ff782aa50364f0c21712b6b4409fd269e5d38","author":{"email":"607a4aeae37c8a26eb86f95c436fb926ad94d55c@apple.com","name":"Pete Cooper"},"message":"Fix incorrect kill flags in fastisel.\n\nIf called twice in the same BB on the same constant, FastISel::fastEmit_ri_ was marking the materialized vreg as killed on each use, instead of only the last use.\n\nChange this to only mark the last use as killed by making earlier uses check if the vreg is already used elsewhere.\n\ngit-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@236650 91177308-0d34-0410-b5e6-96231b3b80d8","distinct":true,"url":"https://api.github.com/repos/J-Liu/llvm/commits/537ff782aa50364f0c21712b6b4409fd269e5d38"},{"sha":"b6ca45c39fd1cae93225bf517cc15b72c4da9686","author":{"email":"f2687d141d6df003196c0c086f0a189634ba4557@google.com","name":"Kostya Serebryany"},"message":"[lib/Fuzzer] rename TestOneInput to LLVMFuzzerTestOneInput to make it more unique\n\ngit-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@236652 91177308-0d34-0410-b5e6-96231b3b80d8","distinct":true,"url":"https://api.github.com/repos/J-Liu/llvm/commits/b6ca45c39fd1cae93225bf517cc15b72c4da9686"},{"sha":"43afa429082f1a90e2ca22d73456c2219ec8d774","author":{"email":"4239aa0d2a9a9fe1ca57c7ca6a764f6a324fc92f@google.com","name":"Zachary Turner"},"message":"A few fixes for llvm-symbolizer on Windows.\n\nSpecifically, this patch correctly respects the -demangle option,\nand additionally adds a hidden --relative-address option allows\ninput addresses to be relative to the module load address instead\nof absolute addresses into the image.\n\ngit-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@236653 91177308-0d34-0410-b5e6-96231b3b80d8","distinct":true,"url":"https://api.github.com/repos/J-Liu/llvm/commits/43afa429082f1a90e2ca22d73456c2219ec8d774"},{"sha":"ea89afbb84a9a066335ef2c20d6b4f2f8e6de579","author":{"email":"4239aa0d2a9a9fe1ca57c7ca6a764f6a324fc92f@google.com","name":"Zachary Turner"},"message":"Fix link failure on MinGW due to use of CoInitialize.\n\nole32 is considered a default library with MSVC, but apparently\nnot with MinGW.  Since we use CoInitialize, we need to explicitly\nlink against it in LLVMSupport for a MinGW build.\n\ngit-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@236654 91177308-0d34-0410-b5e6-96231b3b80d8","distinct":true,"url":"https://api.github.com/repos/J-Liu/llvm/commits/ea89afbb84a9a066335ef2c20d6b4f2f8e6de579"}]}