summaryrefslogtreecommitdiffstats
path: root/llvm/lib
Commit message (Collapse)AuthorAgeFilesLines
...
* MemorySSA: Remove argument to createNewAccess function.Peter Collingbourne2016-05-261-4/+3
| | | | | | | | There is only one caller of MemorySSA::createNewAccess, and it passes true as the IgnoreNonMemory argument. Remove that argument and fold its behavior into createNewAccess. llvm-svn: 270812
* PR11740: Disable assembly debug info when assembly already contains line ↵David Blaikie2016-05-261-5/+4
| | | | | | | | | | | | | | | | | | | | | | | | | directives If there is already debug info in the assembly file, and user hope to use -g option for compiling, we think we should not directly report an error. According to what GNU assembler did, it just reused the debug info in the assembly file, and turned off the DEBUG_TYPE option so that there will be no new debug info emitted by assembler. This fix is just as what GNU assembler did. The concern is the situation that there are two .text sections in the assembly file, one with debug info and the other one without. Currently with this fix, the assembler will no longer generate any debug info for the second .text section. And this is what GNU assembler exactly did for this situation. So I think this still make some sense. Patch by Zhizhou Yang! Differential Revision: http://reviews.llvm.org/D20002 llvm-svn: 270806
* [IRCE] Optimize conjunctions of range checksSanjoy Das2016-05-261-51/+69
| | | | | | | | | | | | | After this change, we do the expected thing for cases like ``` Check0Passed = /* range check IRCE can optimize */ Check1Passed = /* range check IRCE can optimize */ if (!(Check0Passed && Check1Passed)) throw_Exception(); ``` llvm-svn: 270804
* [IRCE] Refactor out a parseRangeCheckFromCond; NFCSanjoy Das2016-05-261-50/+39
| | | | | | | This will later hold more general logic to parse conjunctions of range checks. llvm-svn: 270802
* [PM] Port PartiallyInlineLibCalls to the new pass manager.Davide Italiano2016-05-254-39/+57
| | | | llvm-svn: 270798
* Revert "[MC] Support symbolic expressions in assembly directives"Reid Kleckner2016-05-254-102/+34
| | | | | | This reverts commit r270786, it causes the directive_fill.s to fail. llvm-svn: 270795
* [codeview] Use comdats for debug info describing comdat functionsReid Kleckner2016-05-252-12/+57
| | | | | | | | | | | | | | | | | | Summary: This allows the linker to discard unused symbol information for comdat functions that were discarded during the link. Before this change, searching for the name of an inline function in the debugger would return multiple results, one per symbol subsection in the object file. After this change, there is only one result, the result for the function chosen by the linker. Reviewers: zturner, majnemer Subscribers: aaboud, amccarth, llvm-commits Differential Revision: http://reviews.llvm.org/D20642 llvm-svn: 270792
* Objective-C Class Properties: Autoupgrade "Class Properties" module flag.Manman Ren2016-05-253-0/+35
| | | | | | | | | | When we have "Image Info Version" module flag but don't have "Class Properties" module flag, set "Class Properties" module flag to 0, so we can correctly emit errors when one module has the flag set and another module does not. rdar://26469641 llvm-svn: 270791
* [NVPTX] Don't (incorrectly) say that the NVVMReflect pass preserves all ↵Justin Lebar2016-05-251-3/+0
| | | | | | | | | | | | analyses. Reviewers: tra Subscribers: jholewinski, llvm-commits Differential Revision: http://reviews.llvm.org/D20585 llvm-svn: 270790
* [MC] Support symbolic expressions in assembly directivesPetr Hosek2016-05-254-34/+102
| | | | | | | | | This matches the behavior of GNU assembler which supports symbolic expressions in absolute expressions used in assembly directives. Differential Revision: http://reviews.llvm.org/D20337 llvm-svn: 270786
* Don't repeat name in comment and git-clang-format.Rafael Espindola2016-05-251-5/+5
| | | | llvm-svn: 270785
* Work around an MSVC compiler issue in r270776.Adrian Prantl2016-05-251-3/+3
| | | | llvm-svn: 270783
* [LazyValueInfo] Simplify `return after else`. NFCI.Davide Italiano2016-05-251-4/+3
| | | | llvm-svn: 270779
* [BasicAA] Improve precision of alloca vs. inbounds GEP alias queriesMichael Kuperstein2016-05-251-82/+120
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | If a we have (a) a GEP and (b) a pointer based on an alloca, and the beginning of the object the GEP points would have a negative offset with repsect to the alloca, then the GEP can not alias pointer (b). For example, consider code like: struct { int f0, int f1, ...} foo; ... foo alloca; foo *random = bar(alloca); int *f0 = &alloca.f0 int *f1 = &random->f1; Which is lowered, approximately, to: %alloca = alloca %struct.foo %random = call %struct.foo* @random(%struct.foo* %alloca) %f0 = getelementptr inbounds %struct, %struct.foo* %alloca, i32 0, i32 0 %f1 = getelementptr inbounds %struct, %struct.foo* %random, i32 0, i32 1 Assume %f1 and %f0 alias. Then %f1 would point into the object allocated by %alloca. Since the %f1 GEP is inbounds, that means %random must also point into the same object. But since %f0 points to the beginning of %alloca, the highest %f1 can be is (%alloca + 3). This means %random can not be higher than (%alloca - 1), and so is not inbounds, a contradiction. Differential Revision: http://reviews.llvm.org/D20495 llvm-svn: 270777
* 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
OpenPOWER on IntegriCloud