summaryrefslogtreecommitdiffstats
path: root/llvm/lib/IR
Commit message (Collapse)AuthorAgeFilesLines
...
* fix typo 'varaible' in assertNico Weber2016-08-241-1/+1
| | | | llvm-svn: 279636
* Fix some Clang-tidy modernize-use-using and Include What You Use warnings; ↵Eugene Zelenko2016-08-231-2/+6
| | | | | | | | other minor fixes. Differential revision: https://reviews.llvm.org/D23789 llvm-svn: 279535
* [Profile] refactor meta data copying/swapping codeXinliang David Li2016-08-232-20/+44
| | | | | | Differential Revision: http://reviews.llvm.org/D23619 llvm-svn: 279523
* Add comments and an assert to follow-up on r279113. NFC.Pete Cooper2016-08-221-0/+2
| | | | | | | | | | | Philip commented on r279113 to ask for better comments as to when to use the different versions of getName. Its also possible to assert in the simple case that we aren't an overloaded intrinsic as those have to use the more capable version of getName. Thanks for the comments Philip. llvm-svn: 279466
* [PM] Introduce an abstraction for all the analyses over a particular IRChandler Carruth2016-08-201-0/+2
| | | | | | | | | | | | | | | | | | unit for use in the PreservedAnalyses set. This doesn't have any important functional change yet but it cleans things up and makes the analysis substantially more efficient by avoiding querying through the type erasure for every analysis. I also think it makes it much easier to reason about how analyses are preserved when walking across pass managers and across IR unit abstractions. Thanks to Sean and Mehdi both for the comments and suggestions. Differential Revision: https://reviews.llvm.org/D23691 llvm-svn: 279360
* Add a version of Intrinsic::getName which is more efficient when there are ↵Pete Cooper2016-08-181-0/+5
| | | | | | | | | | | | | no overloads. When running 'opt -O2 verify-uselistorder-nodbg.lto.bc', there are 33m allocations. 8.2m come from std::string allocations in Intrinsic::getName(). Turns out this method only returns a std::string because it needs to handle overloads, but that is not the common case. This adds an overload of getName which just returns a StringRef when there are no overloads and so saves on the allocations. llvm-svn: 279113
* Replace a few more "fall through" comments with LLVM_FALLTHROUGHJustin Bogner2016-08-171-3/+3
| | | | | | Follow up to r278902. I had missed "fall through", with a space. llvm-svn: 278970
* GlobalISel: support irtranslation of icmp instructions.Tim Northover2016-08-172-35/+36
| | | | llvm-svn: 278969
* [GenericDomTree] Change GenericDomTree to use NodeRef in GraphTraits. NFC.Tim Shen2016-08-171-2/+6
| | | | | | | | | | | | | | | | | | Summary: Looking at the implementation, GenericDomTree has more specific requirements on NodeRef, e.g. NodeRefObject->getParent() should compile, and NodeRef should be a pointer. We can remove the pointer requirement, but it seems to have little gain, given the limited use cases. Also changed GraphTraits<Inverse<Inverse<T>> to be more accurate. Reviewers: dblaikie, chandlerc Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D23593 llvm-svn: 278961
* Replace "fallthrough" comments with LLVM_FALLTHROUGHJustin Bogner2016-08-173-4/+4
| | | | | | | This is a mechanical change of comments in switches like fallthrough, fall-through, or fall-thru to use the LLVM_FALLTHROUGH macro instead. llvm-svn: 278902
* Scalar: Avoid dereferencing end() in IndVarSimplifyDuncan P. N. Exon Smith2016-08-171-2/+7
| | | | | | | | | IndVarSimplify::sinkUnusedInvariants calls BasicBlock::getFirstInsertionPt on the ExitBlock and moves instructions before it. This can return end(), so it's not safe to dereference. Add an iterator-based overload to Instruction::moveBefore to avoid the UB. llvm-svn: 278886
* Make MDNode::intersect faster than O(n * m)David Majnemer2016-08-161-5/+4
| | | | | | | | It is pretty easy to get it down to O(nlogn + mlogm). This implementation has the added benefit of automatically deduplicating entries between the two sets. llvm-svn: 278837
* Don't passively concatenate MDNodesDavid Majnemer2016-08-161-13/+5
| | | | | | | | | | | I have audited all the callers of concatenate and none require duplicate entries to service concatenation. These duplicates serve no purpose but to needlessly embiggen the IR. N.B. Layering getMostGenericAliasScope on top of concatenate makes it O(nlogn + mlogm) instead of O(n*m). llvm-svn: 278836
* Revert "Revert "Invariant start/end intrinsics overloaded for address space""Mehdi Amini2016-08-131-1/+27
| | | | | | This reverts commit 32fc6488e48eafc0ca1bac1bd9cbf0008224d530. llvm-svn: 278609
* Revert "Invariant start/end intrinsics overloaded for address space"Mehdi Amini2016-08-131-27/+1
| | | | | | This reverts commit r276447. llvm-svn: 278608
* Fix some Clang-tidy modernize-use-using and Include What You Use warnings.Eugene Zelenko2016-08-131-13/+52
| | | | | | Differential revision: https://reviews.llvm.org/D23478 llvm-svn: 278583
* [Coroutines]: Part6b: Add coro.id intrinsic.Gor Nishanov2016-08-121-2/+2
| | | | | | | | | | | | | | | Summary: 1. Make coroutine representation more robust against optimization that may duplicate instruction by introducing coro.id intrinsics that returns a token that will get fed into coro.alloc and coro.begin. Due to coro.id returning a token, it won't get duplicated and can be used as reliable indicator of coroutine identify when a particular coroutine call gets inlined. 2. Move last three arguments of coro.begin into coro.id as they will be shared if coro.begin will get duplicated. 3. doc + test + code updated to support the new intrinsic. Reviewers: mehdi_amini, majnemer Subscribers: mehdi_amini, llvm-commits Differential Revision: https://reviews.llvm.org/D23412 llvm-svn: 278481
* Use the range variant of transform instead of unpacking begin/endDavid Majnemer2016-08-121-1/+2
| | | | | | No functionality change is intended. llvm-svn: 278476
* Use the range variant of remove_if instead of unpacking begin/endDavid Majnemer2016-08-121-3/+1
| | | | | | No functionality change is intended. llvm-svn: 278475
* Use the range variant of find/find_if instead of unpacking begin/endDavid Majnemer2016-08-122-4/+4
| | | | | | | | | If the result of the find is only used to compare against end(), just use is_contained instead. No functionality change is intended. llvm-svn: 278469
* Use the range variant of find instead of unpacking begin/endDavid Majnemer2016-08-112-8/+5
| | | | | | | | | If the result of the find is only used to compare against end(), just use is_contained instead. No functionality change is intended. llvm-svn: 278433
* Use range algorithms instead of unpacking begin/endDavid Majnemer2016-08-113-14/+13
| | | | | | No functionality change is intended. llvm-svn: 278417
* IR: Don't cast the end iterator to Instruction*Duncan P. N. Exon Smith2016-08-111-2/+2
| | | | | | | | | | | End iterators are usually sentinels, not actually Instruction* at all. Stop casting to it just to get an iterator back. There is likely no observable functionality change here right now (although this is relying on UB, I doubt it was triggering anything), but I'll be removing the cast soon. llvm-svn: 278346
* [Statepoints] Minor cosmetic change; NFCSanjoy Das2016-08-111-1/+1
| | | | | | The verification failure message was missing a space. llvm-svn: 278309
* [x86] Fix a bug in the auto-upgrade from r276416 where we failed to giveChandler Carruth2016-08-101-1/+1
| | | | | | | | | | | | | | | | | | | a sufficiently low alignment for the IR load created. There is no test case because we don't have any test cases for the *IR* produced by the autoupgrade, only the x86 assembly, and it happens that the x86 assembly for this intrinsic as it is tested in the autoupgrade path just happens to not produce a separate load instruction where we might have observed the alignment. I'm going to follow up on the original commit to suggest getting IR-level testing in addition to the asm level testing here so that we can see and test these kinds of issues. We might never get an x86 instruction out with an alignment constraint, but we could stil miscompile code by folding against the alignment marked on (or inferred for in this case) the load. llvm-svn: 278203
* [IR] Remove some unused #includes (NFC)Vedant Kumar2016-08-091-4/+0
| | | | | | | | | | | | I needed a reader-writer lock for a downstream project and noticed that llvm has one. Function.cpp is the only file in-tree that refers to it. To anyone reading this: are you using RWMutex in out-of-tree code? Maybe it's not worth keeping around any more... Since we're not actually using RWMutex *here*, remove the #include (and a few other stale headers while we're at it). llvm-svn: 278178
* Consistently use ModuleAnalysisManagerSean Silva2016-08-091-1/+1
| | | | | | | | | | | Besides a general consistently benefit, the extra layer of indirection allows the mechanical part of https://reviews.llvm.org/D23256 that requires touching every transformation and analysis to be factored out cleanly. Thanks to David for the suggestion. llvm-svn: 278078
* Consistently use FunctionAnalysisManagerSean Silva2016-08-092-2/+2
| | | | | | | | | | | Besides a general consistently benefit, the extra layer of indirection allows the mechanical part of https://reviews.llvm.org/D23256 that requires touching every transformation and analysis to be factored out cleanly. Thanks to David for the suggestion. llvm-svn: 278077
* Move helpers into anonymous namespaces. NFC.Benjamin Kramer2016-08-061-5/+3
| | | | llvm-svn: 277916
* Part 4c: Coroutine Devirtualization: Devirtualize coro.resume and coro.destroy.Gor Nishanov2016-08-061-0/+14
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: This is the 4c patch of the coroutine series. CoroElide pass now checks if PostSplit coro.begin is referenced by coro.subfn.addr intrinsics. If so replace coro.subfn.addrs with an appropriate coroutine subfunction associated with that coro.begin. Documentation and overview is here: http://llvm.org/docs/Coroutines.html. Upstreaming sequence (rough plan) 1.Add documentation. (https://reviews.llvm.org/D22603) 2.Add coroutine intrinsics. (https://reviews.llvm.org/D22659) 3.Add empty coroutine passes. (https://reviews.llvm.org/D22847) 4.Add coroutine devirtualization + tests. ab) Lower coro.resume and coro.destroy (https://reviews.llvm.org/D22998) c) Do devirtualization <= we are here 5.Add CGSCC restart trigger + tests. 6.Add coroutine heap elision + tests. 7.Add the rest of the logic (split into more patches) Reviewers: majnemer Subscribers: mehdi_amini, llvm-commits Differential Revision: https://reviews.llvm.org/D23229 llvm-svn: 277908
* [AutoFDO] Fix handling of empty profilesDavid Callahan2016-08-051-1/+4
| | | | | | | | | | | | | | | Summary: If a profile has no samples for a function, then the function "entry count" is set to the value 0. Several places in the code test that if the Function::getEntryCount is defined at all. Here we change to treat a 0 entry count the same as undefined. In particular, this fixes a problem in getLayoutSuccessorProbThreshold in MachineBlockPlacement.cpp where we use a different and inferior heuristic for laying out basic blocks. Reviewers: danielcdh, dnovillo Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D23082 llvm-svn: 277849
* [coroutines] Part 4[ab]: Coroutine Devirtualization: Lower coro.resume and ↵David Majnemer2016-08-041-2/+4
| | | | | | | | | | | | | | | | coro.destroy. This is the forth patch in the coroutine series. CoroEaly pass now lowers coro.resume and coro.destroy intrinsics by replacing them with an indirect call to an address returned by coro.subfn.addr intrinsic. This is done so that CGPassManager recognizes devirtualization when CoroElide replaces a call to coro.subfn.addr with an appropriate function address. Patch by Gor Nishanov! Differential Revision: https://reviews.llvm.org/D22998 llvm-svn: 277765
* IR: Drop uniquing when an MDNode Value operand is deletedDuncan P. N. Exon Smith2016-08-031-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This is a fix for PR28697. An MDNode can indirectly refer to a GlobalValue, through a ConstantAsMetadata. When the GlobalValue is deleted, the MDNode operand is reset to `nullptr`. If the node is uniqued, this can lead to a hard-to-detect cache invalidation in a Metadata map that's shared across an LLVMContext. Consider: 1. A map from Metadata* to `T` called RemappedMDs. 2. A node that references a global variable, `!{i1* @GV}`. 3. Insert `!{i1* @GV} -> SomeT` in the map. 4. Delete `@GV`, leaving behind `!{null} -> SomeT`. Looking up the generic and uninteresting `!{null}` gives you `SomeT`, which is likely related to `@GV`. Worse, `SomeT`'s lifetime may be tied to the deleted `@GV`. This occurs in practice in the shared ValueMap used since r266579 in the IRMover. Other code that handles more than one Module (with different lifetimes) in the same LLVMContext could hit it too. The fix here is a partial revert of r225223: in the rare case that an MDNode operand is a ConstantAsMetadata (i.e., wrapping a node from the Value hierarchy), drop uniquing if it gets replaced with `nullptr`. This changes step #4 above to leave behind `distinct !{null} -> SomeT`, which can't be confused with the generic `!{null}`. In theory, this can cause some churn in the LLVMContext's MDNode uniquing map when Values are being deleted. However: - The number of GlobalValues referenced from uniqued MDNodes is expected to be quite small. E.g., the debug info metadata schema only references GlobalValues from distinct nodes. - Other Constants have the lifetime of the LLVMContext, whose teardown is careful to drop references before deleting the constants. As a result, I don't expect a compile time regression from this change. llvm-svn: 277625
* [Verifier] Disallow illegal ptr<->int casts in ConstantExprsSanjoy Das2016-08-021-8/+22
| | | | | | | This should have been a part of rL277085, but I hadn't considered this case. llvm-svn: 277413
* Tie the Verifier class to a Module; NFCISanjoy Das2016-08-021-72/+67
| | | | | | | | | | | | | | | | | | | | | | | | | | Summary: This commit changes the Verifier class to accept a Module via the constructor to make it obvious that a specific instance of the class is only intended to work with a specific module. The `updateModule` setter (despite being private) was making this fact less transparent. There are fields in the `Verifier` class like `DeoptimizeDeclarations` and `GlobalValueVisited` which are module specific, so a given Verifier instance will not in fact work across multiple modules today. This change just makes that more obvious. The motivation is to make it easy to get to the datalayout of the module unambiguously. That is required to verify that `inttoptr` and `ptrtoint` constant expressions are well typed in the face of non-integral pointer types. Reviewers: dexonsmith, bkramer, majnemer, chandlerc Subscribers: mehdi_amini, mcrosier, llvm-commits Differential Revision: https://reviews.llvm.org/D23040 llvm-svn: 277409
* [Verifier] Resume instructions can only be in functions w/ a personalityDavid Majnemer2016-08-011-0/+16
| | | | | | This fixes PR28799. llvm-svn: 277360
* Fixed "copy-paste" mistake from revision 255245.Amjad Aboud2016-07-311-1/+1
| | | | llvm-svn: 277290
* CodeGen: add new "intrinsic" MachineOperand kind.Tim Northover2016-07-291-4/+2
| | | | | | | This will be used during GlobalISel, where we need a more robust and readable way to write tests than a simple immediate ID. llvm-svn: 277209
* Revert "Don't invoke getName() from Function::isIntrinsic().", rL276942.Justin Lebar2016-07-283-6/+9
| | | | | | | | | This broke some out-of-tree AMDGPU tests that relied on the old behavior wherein isIntrinsic() would return true for any function that starts with "llvm.". And in general that change will not play nicely with out-of-tree backends. llvm-svn: 277087
* [IR] Introduce a non-integral pointer typeSanjoy Das2016-07-282-0/+24
| | | | | | | | | | | | | | | Summary: This change adds a `ni` specifier in the `datalayout` string to denote pointers in some given address spaces as "non-integral", and adds some typing rules around these special pointers. Reviewers: majnemer, chandlerc, atrick, dberlin, eli.friedman, tstellarAMD, arsenm Subscribers: arsenm, mcrosier, llvm-commits Differential Revision: https://reviews.llvm.org/D22488 llvm-svn: 277085
* Don't invoke getName() from Function::isIntrinsic().Justin Lebar2016-07-273-9/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: getName() involves a hashtable lookup, so is expensive given how frequently isIntrinsic() is called. (In particular, many users cast to IntrinsicInstr or one of its subclasses before calling getIntrinsicID().) This has an incidental functional change: Before, isIntrinsic() would return true for any function whose name started with "llvm.", even if it wasn't properly an intrinsic. The new behavior seems more correct to me, because it's strange to say that isIntrinsic() is true, but getIntrinsicId() returns "not an intrinsic". Some callers want the old behavior -- they want to know whether the caller is a recognized intrinsic, or might be one in some other version of LLVM. For them, we added Function::hasLLVMReservedName(), which checks whether the name starts with "llvm.". This change is good for a 1.5% e2e speedup compiling a large Eigen benchmark. Reviewers: bogner Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D22065 llvm-svn: 276942
* Add invariant start call creation in IRBuilder.NFCAnna Thomas2016-07-221-0/+20
| | | | | | Differential Revision: https://reviews.llvm.org/D22700 llvm-svn: 276471
* Invariant start/end intrinsics overloaded for address spaceAnna Thomas2016-07-221-1/+27
| | | | | | | | | | | | | | | | | | | | | | Summary: The llvm.invariant.start and llvm.invariant.end intrinsics currently support specifying invariant memory objects only in the default address space. With this change, these intrinsics are overloaded for any adddress space for memory objects and we can use these llvm invariant intrinsics in non-default address spaces. Example: llvm.invariant.start.p1i8(i64 4, i8 addrspace(1)* %ptr) This overloaded intrinsic is needed for representing final or invariant memory in managed languages. Reviewers: apilipenko, reames Subscribers: llvm-commits llvm-svn: 276447
* [X86][AVX] Added support for lowering to VBROADCASTF128/VBROADCASTI128 ↵Simon Pilgrim2016-07-221-7/+14
| | | | | | | | | | | | | | | | (reapplied) As reported on PR26235, we don't currently make use of the VBROADCASTF128/VBROADCASTI128 instructions (or the AVX512 equivalents) to load+splat a 128-bit vector to both lanes of a 256-bit vector. This patch enables lowering from subvector insertion/concatenation patterns and auto-upgrades the llvm.x86.avx.vbroadcastf128.pd.256 / llvm.x86.avx.vbroadcastf128.ps.256 intrinsics to match. We could possibly investigate using VBROADCASTF128/VBROADCASTI128 to load repeated constants as well (similar to how we already do for scalar broadcasts). Reapplied with fix for PR28657 - removed intrinsic definitions (clang companion patch to be be submitted shortly). Differential Revision: https://reviews.llvm.org/D22460 llvm-svn: 276416
* Revert "[X86][AVX] Added support for lowering to VBROADCASTF128/VBROADCASTI128"Benjamin Kramer2016-07-221-14/+7
| | | | | | | | It caused PR28657. This reverts commit r276281. llvm-svn: 276405
* Revert "Invariant start/end intrinsics overloaded for address space"Anna Thomas2016-07-211-27/+1
| | | | | | This reverts commit r276316. llvm-svn: 276320
* Invariant start/end intrinsics overloaded for address spaceAnna Thomas2016-07-211-1/+27
| | | | | | | | | | | | | | | | | | | | | Summary: The llvm.invariant.start and llvm.invariant.end intrinsics currently support specifying invariant memory objects only in the default address space. With this change, these intrinsics are overloaded for any adddress space for memory objects and we can use these llvm invariant intrinsics in non-default address spaces. Example: llvm.invariant.start.p1i8(i64 4, i8 addrspace(1)* %ptr) This overloaded intrinsic is needed for representing final or invariant memory in managed languages. Reviewers: tstellarAMD, reames, apilipenko Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D22519 llvm-svn: 276316
* [X86][AVX] Added support for lowering to VBROADCASTF128/VBROADCASTI128Simon Pilgrim2016-07-211-7/+14
| | | | | | | | | | | | As reported on PR26235, we don't currently make use of the VBROADCASTF128/VBROADCASTI128 instructions (or the AVX512 equivalents) to load+splat a 128-bit vector to both lanes of a 256-bit vector. This patch enables lowering from subvector insertion/concatenation patterns and auto-upgrades the llvm.x86.avx.vbroadcastf128.pd.256 / llvm.x86.avx.vbroadcastf128.ps.256 intrinsics to match. We could possibly investigate using VBROADCASTF128/VBROADCASTI128 to load repeated constants as well (similar to how we already do for scalar broadcasts). Differential Revision: https://reviews.llvm.org/D22460 llvm-svn: 276281
* Rename StringMap::emplace_second to try_emplace.Benjamin Kramer2016-07-211-1/+1
| | | | | | | Coincidentally this function maps to the C++17 try_emplace. Rename it for consistentcy with C++17 std::map. NFC. llvm-svn: 276276
* Add missing import to fix the buildAmaury Sechet2016-07-211-0/+1
| | | | llvm-svn: 276237
OpenPOWER on IntegriCloud