summaryrefslogtreecommitdiffstats
path: root/llvm/lib
Commit message (Collapse)AuthorAgeFilesLines
* PR26055: Speed up LiveDebugValues by replacing lists with bitvectors.Adrian Prantl2016-05-251-143/+183
| | | | | | | | | | | | | | | | | | | | | This patch modifies the LiveDebugValues pass to use more efficient set data structures as outlined in PR26055. Both VarLocSet and VarLocList are now SparseBitVectors which allows us to perform much faster bitvector arithmetic on them. The speedup can be in the order of minutes especially on ASANified code. The change is not NFC in the assembler output because the inserted DBG_VALUEs are now sorted by variable and location. Many thanks to Daniel Berlin for helping design the improved algorithm and reviewing the patch. https://llvm.org/bugs/show_bug.cgi?id=26055 http://reviews.llvm.org/D20178 rdar://problem/24091200 llvm-svn: 270776
* [MBB] Early exit to reduce indentation, per coding guidelines. NFC.Chad Rosier2016-05-251-59/+62
| | | | llvm-svn: 270773
* Look for a loop's starting location in the llvm.loop metadataHal Finkel2016-05-251-0/+21
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | Getting accurate locations for loops is important, because those locations are used by the frontend to generate optimization remarks. Currently, optimization remarks for loops often appear on the wrong line, often the first line of the loop body instead of the loop itself. This is confusing because that line might itself be another loop, or might be somewhere else completely if the body was inlined function call. This happens because of the way we find the loop's starting location. First, we look for a preheader, and if we find one, and its terminator has a debug location, then we use that. Otherwise, we look for a location on an instruction in the loop header. The fallback heuristic is not bad, but will almost always find the beginning of the body, and not the loop statement itself. The preheader location search often fails because there's often not a preheader, and even when there is a preheader, depending on how it was formed, it sometimes carries the location of some preceeding code. I don't see any good theoretical way to fix this problem. On the other hand, this seems like a straightforward solution: Put the debug location in the loop's llvm.loop metadata. A companion Clang patch will cause Clang to insert llvm.loop metadata with appropriate locations when generating debugging information. With these changes, our loop remarks have much more accurate locations. Differential Revision: http://reviews.llvm.org/D19738 llvm-svn: 270771
* Sort includes.Rafael Espindola2016-05-251-1/+1
| | | | llvm-svn: 270769
* Port the strip-invalid-debuginfo logic to the legacy verifier pass, too.Adrian Prantl2016-05-251-6/+16
| | | | | | | | | | | | | | | | | | | | | Since r268966 the modern Verifier pass defaults to stripping invalid debug info in nonasserts builds. This patch ports this behavior back to the legacy Verifier pass as well. The primary motivation is that the clang frontend accepts bitcode files as input but is still using the legacy pass pipeline. Background: The problem I'm trying to solve with this sequence of patches is that historically we've done a really bad job at verifying debug info. We want to be able to make the verifier stricter without having to worry about breaking bitcode compatibility with existing producers. For example, we don't necessarily want IR produced by an older version of clang to be rejected by an LTO link just because of malformed debug info, and rather provide an option to strip it. Note that merely outdated (but well-formed) debug info would continue to be auto-upgraded in this scenario. http://reviews.llvm.org/D20629 <rdar://problem/26448800> llvm-svn: 270768
* Move whole-program virtual call optimization pass after function attribute ↵Peter Collingbourne2016-05-251-24/+27
| | | | | | | | | | | | | | | | | | inference in LTO pipeline. As a result of D18634 we no longer infer certain attributes on linkonce_odr functions at compile time, and may only infer them at LTO time. The readnone attribute in particular is required for virtual constant propagation (part of whole-program virtual call optimization) to work correctly. This change moves the whole-program virtual call optimization pass after the function attribute inference passes, and enables the attribute inference passes at opt level 1, so that virtual constant propagation has a chance to work correctly for linkonce_odr functions. Differential Revision: http://reviews.llvm.org/D20643 llvm-svn: 270765
* [TLI] Also cover Linux 64 libfunc (stat64, ...) prototype checking.Ahmed Bougacha2016-05-251-2/+2
| | | | | | My script missed those in r270750. llvm-svn: 270763
* fix typo; NFCSanjay Patel2016-05-251-1/+1
| | | | llvm-svn: 270760
* ValueMaterializer: rename materializeDeclFor() to materialize()Mehdi Amini2016-05-252-7/+7
| | | | | | | | | | It may materialize a declaration, or a definition. The name could be misleading. This is following a merge of materializeInitFor() into materializeDeclFor(). Differential Revision: http://reviews.llvm.org/D20593 llvm-svn: 270759
* ValueMaterializer: fuse materializeDeclFor and materializeInitFor (NFC)Mehdi Amini2016-05-252-37/+23
| | | | | | | | | | | | They were originally separated to handle the co-recursion between the ValueMapper and the ValueMaterializer. This recursion does not exist anymore: the ValueMapper now uses a Worklist and the ValueMaterializer is scheduling job on the Worklist. Differential Revision: http://reviews.llvm.org/D20593 From: Mehdi Amini <mehdi.amini@apple.com> llvm-svn: 270758
* IRLinker: fix double scheduling of mapping a global value because of an aliasMehdi Amini2016-05-251-0/+11
| | | | | | | | | | | | This test was hitting an assertion in the value mapper because the IRLinker was trying to map two times @A while materializing the initializer for @C. Fix http://llvm.org/PR27850 Differential Revision: http://reviews.llvm.org/D20586 llvm-svn: 270757
* [libfuzzer] replacing unittest for truncate_units with functional test.Mike Aizatsky2016-05-254-22/+22
| | | | | | Differential Revision: http://reviews.llvm.org/D20641 llvm-svn: 270755
* Simplify std::all_of/any_of predicates by using llvm::all_of/any_of. NFCI.Simon Pilgrim2016-05-251-7/+5
| | | | llvm-svn: 270753
* [codeview] Move StreamInterface and StreamReader to libcodeview.Zachary Turner2016-05-2513-31/+97
| | | | | | | | | | We have need to reuse this functionality, including making additional generic stream types that are smarter about how and when they copy memory versus referencing the original memory. So all of these structures belong in the common library rather than being pdb specific. llvm-svn: 270751
* [TLI] Fix NumParams==0 prototype checking typo.Ahmed Bougacha2016-05-251-57/+43
| | | | | | | | | | | | | There was a typo in r267758. It caused invalid accesses when given something like "void @free(...)", as NumParams == 0, and we then try to look at the 0th parameter. Turns out, most of these were untested; add both attribute and missing-prototype checks for all libc libfuncs. Differential Revision: http://reviews.llvm.org/D20543 llvm-svn: 270750
* Simplify std::all_of predicate (to one line) by using llvm::all_of. NFCI.Simon Pilgrim2016-05-251-2/+1
| | | | llvm-svn: 270749
* Simplify std::all_of predicate (to one line) by using llvm::all_of. NFCI.Simon Pilgrim2016-05-251-3/+1
| | | | llvm-svn: 270747
* Fix shouldAssumeDSOLocal for private linkage.Rafael Espindola2016-05-251-1/+1
| | | | llvm-svn: 270746
* [IR] Copy comdats in GlobalObject::copyAttributesFromReid Kleckner2016-05-252-0/+6
| | | | | | | | | | | | | | This is probably correct for all uses except cross-module IR linking, where we need to move the comdat from the source module to the destination module. Fixes PR27870. Reviewers: majnemer Differential Revision: http://reviews.llvm.org/D20631 llvm-svn: 270743
* AMDGPU: Fix v2i64/v2f64 bitcastsMatt Arsenault2016-05-251-0/+2
| | | | | | | These operations tend to get promoted away to v4i32 so this doesn't happen often. llvm-svn: 270740
* [SelectionDAG] Add smarts for BSWAP in computeKnownBits.Chad Rosier2016-05-251-0/+6
| | | | llvm-svn: 270738
* [PM] CorrelatedValuePropagation: pass state to function. NFCI.Davide Italiano2016-05-251-29/+16
| | | | | | | While here, convert the logic of the pass to use static function(s). This is in preparation for porting this pass to the new PM. llvm-svn: 270734
* AMDGPU: Fix inconsistent lowering of select of vectorsMatt Arsenault2016-05-251-1/+9
| | | | | | | | | f32 vectors would use a sequence of BFI instructions instead of unrolled cmp + select. This was better in the case of a VALU select with SGPR inputs, but we don't have a way of dealing with that in the DAG. llvm-svn: 270731
* [x86] avoid code explosion from LoopVectorizer for gather loop (PR27826) Sanjay Patel2016-05-251-2/+10
| | | | | | | | | | | | | | By making pointer extraction from a vector more expensive in the cost model, we avoid the vectorization of a loop that is very likely to be memory-bound: https://llvm.org/bugs/show_bug.cgi?id=27826 There are still bugs related to this, so we may need a more general solution to avoid vectorizing obviously memory-bound loops when we don't have HW gather support. Differential Revision: http://reviews.llvm.org/D20601 llvm-svn: 270729
* Use new triple API to check if comdat is supportedXinliang David Li2016-05-251-1/+1
| | | | llvm-svn: 270727
* [obj2yaml] [yaml2obj] MachO support for rebase opcodesChris Bieneman2016-05-251-0/+13
| | | | | | This is the first bit of support for MachO __LINKEDIT segment data. llvm-svn: 270724
* [SDAG] Add a fallback multiplication expansionHal Finkel2016-05-251-1/+43
| | | | | | | | | | | | | | | | | | | | | | | | | | LegalizeIntegerTypes does not have a way to expand multiplications for large integer types (i.e. larger than twice the native bit width). There's no standard runtime call to use in that case, and so we'd just assert. Unfortunately, as it turns out, it is possible to hit this case from standard-ish C code in rare cases. A particular case a user ran into yesterday involved an __int128 induction variable and a loop with a quadratic (not linear) recurrence which triggered some backend logic using SCEVExpander. In this case, the BinomialCoefficient code in SCEV generates some i129 variables, which get widened to i256. At a high level, this is not actually good (i.e. the underlying optimization, PPCLoopPreIncPrep, should not be transforming the loop in question for performance reasons), but regardless, the backend shouldn't crash because of cost-modeling issues in the optimizer. This is a straightforward implementation of the multiplication expansion, based on the algorithm in Hacker's Delight. I validated it against the code for the mul256b function from http://locklessinc.com/articles/256bit_arithmetic/ using random inputs. There should be no functional change for previously-working code (the new expansion code only replaces an assert). Fixes PR19797. llvm-svn: 270720
* [x86, AVX] allow explicit calls to VZERO* to modify state in ↵Sanjay Patel2016-05-251-6/+7
| | | | | | | | | | VZeroUpperInserter pass (PR27823) As noted in the review, there are still problems, so this doesn't the bug completely. Differential Revision: http://reviews.llvm.org/D20529 llvm-svn: 270718
* [RuntimeDyld] Call the SymbolResolver::findSymbolInLogicalDylib method whenLang Hames2016-05-253-6/+8
| | | | | | | | | | | | | | | | | searching for external symbols, and fall back to the SymbolResolver::findSymbol method if the former returns null. This makes RuntimeDyld behave more like a static linker: Symbol definitions from within the current module's "logical dylib" will be preferred to external definitions. We can build on this behavior in the future to properly support weak symbol handling. Custom symbol resolvers that override the findSymbolInLogicalDylib method may notice changes due to this patch. Clients who have not overridden this method should generally be unaffected, however users of the OrcMCJITReplacement class may notice changes. llvm-svn: 270716
* Clarify that we match BSwap in InstCombine and BitReverse in CGP. NFC.Chad Rosier2016-05-254-8/+8
| | | | | | | | Also, rename recognizeBitReverseOrBSwapIdiom to recognizeBSwapOrBitReverseIdiom, so the ordering of the MatchBSwaps and MatchBitReversals arguments are consistent with the function name. llvm-svn: 270715
* [ThinLTO] Refactor ODR resolution and internalization (NFC)Teresa Johnson2016-05-253-174/+177
| | | | | | | | | Move the now index-based ODR resolution and internalization routines out of ThinLTOCodeGenerator.cpp and into either LTO.cpp (index-based analysis) or FunctionImport.cpp (index-driven optimizations). This is to enable usage by other linkers. llvm-svn: 270698
* [SCEV] No-wrap flags are not propagated when folding "{S,+,X}+T ==> {S+T,+,X}"Oleg Ranevskyy2016-05-251-1/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: **Description** This makes `WidenIV::widenIVUse` (IndVarSimplify.cpp) fail to widen narrow IV uses in some cases. The latter affects IndVarSimplify which may not eliminate narrow IV's when there actually exists such a possibility, thereby producing ineffective code. When `WidenIV::widenIVUse` gets a NarrowUse such as `{(-2 + %inc.lcssa),+,1}<nsw><%for.body3>`, it first tries to get a wide recurrence for it via the `getWideRecurrence` call. `getWideRecurrence` returns recurrence like this: `{(sext i32 (-2 + %inc.lcssa) to i64),+,1}<nsw><%for.body3>`. Then a wide use operation is generated by `cloneIVUser`. The generated wide use is evaluated to `{(-2 + (sext i32 %inc.lcssa to i64))<nsw>,+,1}<nsw><%for.body3>`, which is different from the `getWideRecurrence` result. `cloneIVUser` sees the difference and returns nullptr. This patch also fixes the broken LLVM tests by adding missing <nsw> entries introduced by the correction. **Minimal reproducer:** ``` int foo(int a, int b, int c); int baz(); void bar() { int arr[20]; int i = 0; for (i = 0; i < 4; ++i) arr[i] = baz(); for (; i < 20; ++i) arr[i] = foo(arr[i - 4], arr[i - 3], arr[i - 2]); } ``` **Clang command line:** ``` clang++ -mllvm -debug -S -emit-llvm -O3 --target=aarch64-linux-elf test.cpp -o test.ir ``` **Expected result:** The ` -mllvm -debug` log shows that all the IV's for the second `for` loop have been eliminated. Reviewers: sanjoy Subscribers: atrick, asl, aemerson, mzolotukhin, llvm-commits Differential Revision: http://reviews.llvm.org/D20058 llvm-svn: 270695
* [AArch64] Adding a TargetParser for AArch64Renato Golin2016-05-251-0/+219
| | | | | | | | | | There's already a ARMTargetParser,now adding a similar one for aarch64. so we can use it to do ARCH/CPU/FPU parsing in clang and llvm, instead of string comparison. Patch by Jojo Ma. llvm-svn: 270687
* [X86][SSE] Replace (V)CVTDQ2PD(Y) and (V)CVTPS2PD(Y) lossless conversion ↵Simon Pilgrim2016-05-253-31/+42
| | | | | | | | | | intrinsics with generic IR Followup to D20528 clang patch, this removes the (V)CVTDQ2PD(Y) and (V)CVTPS2PD(Y) llvm intrinsics and auto-upgrades to sitofp/fpext instead. Differential Revision: http://reviews.llvm.org/D20568 llvm-svn: 270678
* [X86] Remove the llvm.x86.sse2.storel.dq intrinsic. It hasn't been used in a ↵Craig Topper2016-05-253-9/+20
| | | | | | long time. llvm-svn: 270677
* [Support] Reapply cleanup r270643Gerolf Hoflehner2016-05-251-39/+0
| | | | llvm-svn: 270674
* [FunctionAttrs] Volatile loads should disable readonlyDavid Majnemer2016-05-251-0/+5
| | | | | | | | A volatile load has side effects beyond what callers expect readonly to signify. For example, it is not safe to reorder two function calls which each perform a volatile load to the same memory location. llvm-svn: 270671
* [Support] revert previous commit r270643Gerolf Hoflehner2016-05-251-0/+39
| | | | llvm-svn: 270670
* [llvm-pdbdump] Decipher the remaining PDB streams.Zachary Turner2016-05-251-0/+12
| | | | | | | We know at least know the meaning of every stream of the PDB file. Yay! llvm-svn: 270669
* [llvm-pdbdump] Dump the IPI stream and all records.Zachary Turner2016-05-252-3/+12
| | | | llvm-svn: 270661
* pdbdump: fix bug in name hash table.Rui Ueyama2016-05-251-3/+1
| | | | | | | | | | | name_ids() did not return all IDs but only the first NameCount items. The number of non-zero entries in IDs vector is NameCount, but it does not mean that all non-zero entries are at the beginning of IDs vector. Differential Revision: http://reviews.llvm.org/D20611 llvm-svn: 270656
* [llvm-pdbdump] Stream 0 isn't actually the MSF superblock.Zachary Turner2016-05-251-0/+1
| | | | | | | Oddly enough, I realized we don't actually know what stream 0 is (if anything). llvm-svn: 270655
* [llvm-pdbdump] Dump stream summary list.Zachary Turner2016-05-253-0/+18
| | | | | | | | | Try to figure out what each stream is, and dump its name. This gives us a better picture of what streams we still don't understand. llvm-svn: 270653
* [PM] Port BDCE to the new pass manager.Davide Italiano2016-05-254-35/+43
| | | | llvm-svn: 270647
* Soften assertion in AMDGPU emitPrologue.Nirav Dave2016-05-251-2/+3
| | | | | | | | | | | | | | [AMDGPU] emitPrologue looks for an unused unallocated SGPR that is not the scratch descriptor. Continue search if unused register found fails other requirements. Reviewers: arsenm, tstellarAMD, nhaehnle Subscribers: arsenm, llvm-commits, kzhuravl Differential Revision: http://reviews.llvm.org/D20526 llvm-svn: 270646
* ScheduleDAGInstrs: Fix memory corruptionMatthias Braun2016-05-251-2/+2
| | | | | | | | We have to modify V2SU before inserting new elements into the CurrentVRegDefs set because that may move V2SU in memory invalidating the reference. llvm-svn: 270644
* [Support] Cleanup of an ancient Darwin work-around in Signals.inc (PR26174)Gerolf Hoflehner2016-05-251-39/+0
| | | | | | Patch by Jeremy Huddleston Sequoia llvm-svn: 270643
* [esan|wset] EfficiencySanitizer working set tool fastpathDerek Bruening2016-05-251-0/+104
| | | | | | | | | | | | | | | | | Summary: Adds fastpath instrumentation for esan's working set tool. The instrumentation for an intra-cache-line load or store consists of an inlined write to shadow memory bits for the corresponding cache line. Adds a basic test for this instrumentation. Reviewers: aizatsky Subscribers: vitalybuka, zhaoqin, kcc, eugenis, llvm-commits Differential Revision: http://reviews.llvm.org/D20483 llvm-svn: 270640
* [libFuzzer] print stats if we crash on empty inputKostya Serebryany2016-05-254-3/+27
| | | | llvm-svn: 270639
* Revert r270569 (teach llvm-mc to generate compressed debug sections in zlibRichard Smith2016-05-252-21/+39
| | | | | | style). It appears that current ELF linkers are not ready for this. llvm-svn: 270638
OpenPOWER on IntegriCloud