summaryrefslogtreecommitdiffstats
path: root/llvm/lib/IR
Commit message (Collapse)AuthorAgeFilesLines
* Return a StringRef from getSection.Rafael Espindola2016-05-112-3/+10
| | | | | | This is similar to how getName is handled. llvm-svn: 269218
* [NFC] Remove some dead code:Filipe Cabecinhas2016-05-112-21/+0
| | | | | | | DbgInfoIntrinsic::StripCast() is dead since r79977 The only function that creates Comdat objects seems to be in Module, and always creates them using the default constructor. llvm-svn: 269204
* NFC. Introduce Value::isPointerDereferenceableArtur Pilipenko2016-05-111-0/+23
| | | | | | | | | | Extract a part of isDereferenceableAndAlignedPointer functionality to Value: Reviewed By: hfinkel, sanjoy Differential Revision: http://reviews.llvm.org/D17611 llvm-svn: 269190
* Refactor duplicated check for valid declaration linkage. NFC.Rafael Espindola2016-05-111-2/+1
| | | | llvm-svn: 269184
* Delete duplicated verifier test.Rafael Espindola2016-05-111-5/+0
| | | | | | Also add unittest to show we still detect the errors. llvm-svn: 269182
* Try to fix a msvc warning.Rafael Espindola2016-05-111-0/+1
| | | | llvm-svn: 269178
* Replace PrintLinkage with getLinkagePrintName. NFC.Rafael Espindola2016-05-111-17/+25
| | | | llvm-svn: 269155
* Separate the Verifier into an analysis and a transformation pass andAdrian Prantl2016-05-092-5/+34
| | | | | | | | | | | | | | | | | | | | | | | | allow the transformation to strip invalid debug info. This patch separates the Verifier into an analysis and a transformation pass, with the transformation pass optionally stripping malformed debug info. 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/D19988 rdar://problem/25818489 This reapplies r268937 without modifications. llvm-svn: 268966
* Allow the LTO code generator to strip invalid debug info from the input.Adrian Prantl2016-05-091-3/+7
| | | | | | | | | | | | | | | | | | | | | This patch introduces a new option -lto-strip-invalid-debug-info, which drops malformed debug info from the input. 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. rdar://problem/25818489 http://reviews.llvm.org/D19987 This reapplies 268936 with a test case fix for Linux (-exported-symbol foo) llvm-svn: 268965
* Revert "Allow the LTO code generator to strip invalid debug info from the ↵Adrian Prantl2016-05-091-7/+3
| | | | | | | | input." This reverts commit 268936 while investigating buildbot breakage. llvm-svn: 268940
* Revert "Separate the Verifier into an analysis and a transformation pass and"Adrian Prantl2016-05-092-34/+5
| | | | | | This reverts commit 268937 while investigating build bot breakage. llvm-svn: 268939
* Separate the Verifier into an analysis and a transformation pass andAdrian Prantl2016-05-092-5/+34
| | | | | | | | | | | | | | | | | | | | | | allow the transformation to strip invalid debug info. This patch separates the Verifier into an analysis and a transformation pass, with the transformation pass optionally stripping malformed debug info. 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/D19988 rdar://problem/25818489 llvm-svn: 268937
* Allow the LTO code generator to strip invalid debug info from the input.Adrian Prantl2016-05-091-3/+7
| | | | | | | | | | | | | | | | | | | This patch introduces a new option -lto-strip-invalid-debug-info, which drops malformed debug info from the input. 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. rdar://problem/25818489 http://reviews.llvm.org/D19987 llvm-svn: 268936
* Fix stripDebugInfo: was modifying "DebugLoc" attached to the intrinsic after ↵Mehdi Amini2016-05-071-0/+1
| | | | | | | | | deleting it. Fix MSAN build. From: Mehdi Amini <mehdi.amini@apple.com> llvm-svn: 268849
* Refactor stripDebugInfo(Function) to handle intrinsicMehdi Amini2016-05-071-21/+14
| | | | | | | | | | | | | | This moves the code that handles stripping debug info intrinsic from StripDebugInfo(Module) to StripDebugInfo(Function). The latter is already walking every instructions so it makes sense to do it at the same time. This makes also stripDebugInfo(Function) as an API more useful: it is really dropping every debug info in the Function. Finally the existing code is trigerring an assertion when the Module is not fully materialized. From: Mehdi Amini <mehdi.amini@apple.com> llvm-svn: 268847
* Revert r268832 "Refactor stripDebugInfo(Function) to handle intrinsic"Vitaly Buka2016-05-071-13/+21
| | | | | | It breaks many bots llvm-svn: 268837
* Refactor stripDebugInfo(Function) to handle intrinsicMehdi Amini2016-05-071-21/+13
| | | | | | | | | | | | | | This moves the code that handles stripping debug info intrinsic from StripDebugInfo(Module) to StripDebugInfo(Function). The latter is already walking every instructions so it makes sense to do it at the same time. This makes also stripDebugInfo(Function) as an API more useful: it is really dropping every debug info in the Function. Finally the existing code is trigerring an assertion when the Module is not fully materialized. From: Mehdi Amini <mehdi.amini@apple.com> llvm-svn: 268832
* Refactor the Verifier so it can diagnose IR validation errors and debugAdrian Prantl2016-05-061-159/+195
| | | | | | | | | | | | | | | | | | | | | | | info metadata errors separately. (NFC) This patch refactors the Verifier so it can diagnose IR validation errors and debug info metadata errors separately. The motivation behind this change is that broken (or outdated) debug info can be "recovered" from by stripping the debug info. 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/D19986 rdar://problem/25818489 llvm-svn: 268778
* AMDGPU/SI: Add amdgpu_kernel calling convention. Part 1.Nikolay Haustov2016-05-061-0/+1
| | | | | | | | | | | | | | | | | Summary: This will be used for AMDGPU_HSA_KERNEL symbol type in output ELF. Also, in the future unused non-kernels may be optimized. For now, also accept SPIR_KERNEL for HCC frontend. Also, add bitcode compatibility tests for missing calling conventions except AVR_BUILTIN which doesn't have parse code. Reviewers: tstellarAMD, arsenm Subscribers: arsenm, joker.eph, llvm-commits llvm-svn: 268717
* "Reapply r268521 "[InstCombine] Canonicalize icmp instructions based on ↵Balaram Makam2016-05-041-0/+12
| | | | | | | | | dominating conditions."" This reapplies commit r268521, that was reverted in r268530 due to a test failure in select-implied.ll Modified the test case to reflect the new change. llvm-svn: 268557
* [ConstantFold] Don't try to strip fp -> int bitcasts to simplify icmpsHal Finkel2016-05-041-0/+4
| | | | | | | | | | | | | ConstantFold has logic to take icmp (bitcast x to y), null and strip the bitcast. This makes sense in general, but not if x has floating-point type. In this case, we'd need a fcmp, not an icmp, and the code will assert. We normally don't see this situation because we constant fold fp -> int bitcasts, however, we'll see it for bitcasts of ppc_fp128 -> i128. This is because that bitcast is Endian-dependent, and as a result, we don't simplify it in ConstantFold (we could, but no one has yet added the necessary logic). Regardless, ConstantFold should not depend on that canonicalization for correctness. llvm-svn: 268534
* Revert "[InstCombine] Canonicalize icmp instructions based on dominating ↵Balaram Makam2016-05-041-12/+0
| | | | | | | | conditions." This reverts commit 573a40f79b35cf3e71db331bb00f6a84f03b835d. llvm-svn: 268530
* [InstCombine] Canonicalize icmp instructions based on dominating conditions.Balaram Makam2016-05-041-0/+12
| | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: This patch canonicalizes conditions based on the constant range information of the dominating branch condition. For example: %cmp = icmp slt i64 %a, 0 br i1 %cmp, label %land.lhs.true, label %lor.rhs lor.rhs: %cmp2 = icmp sgt i64 %a, 0 Would now be canonicalized into: %cmp = icmp slt i64 %a, 0 br i1 %cmp, label %land.lhs.true, label %lor.rhs lor.rhs: %cmp2 = icmp ne i64 %a, 0 Reviewers: mcrosier, gberry, t.p.northover, llvm-commits, reames, hfinkel, sanjoy, majnemer Subscribers: MatzeB, majnemer, mcrosier Differential Revision: http://reviews.llvm.org/D18841 llvm-svn: 268521
* Revert "[SimplifyCFG] Extend TryToSimplifyUncondBranchFromEmptyBlock for ↵Reid Kleckner2016-05-021-24/+0
| | | | | | | | | | | empty block including lifetime intrinsics" This reverts commit r268254. This change causes assertion failures while building Chromium. Reduced test case coming soon. llvm-svn: 268288
* [SimplifyCFG] Extend TryToSimplifyUncondBranchFromEmptyBlock for empty block ↵Hans Wennborg2016-05-021-0/+24
| | | | | | | | | | | | | | | | | | including lifetime intrinsics Make it possible that TryToSimplifyUncondBranchFromEmptyBlock merges empty basic block including lifetime intrinsics as well as phi nodes and unconditional branch into its successor or predecessor(s). If successor of empty block has single predecessor, all contents including lifetime intrinsics are sinked into the successor. Otherwise, they are hoisted into its predecessor(s) and then merged into the predecessor(s). Patch by Josh Yoon <josh.yoon@samsung.com>! Differential Revision: http://reviews.llvm.org/D19257 llvm-svn: 268254
* Fixed signed/unsigned comparison warning.Simon Pilgrim2016-05-021-1/+1
| | | | llvm-svn: 268249
* Properly name LLVMSetIsInBounds's argument. NFCAmaury Sechet2016-05-011-2/+2
| | | | llvm-svn: 268176
* clean up documentation comments; NFCSanjay Patel2016-04-291-110/+14
| | | | llvm-svn: 268122
* Unify XDEBUG and EXPENSIVE_CHECKS (into the latter), and add an option to ↵Filipe Cabecinhas2016-04-291-1/+1
| | | | | | | | | | | | | | | | | | | the cmake build to enable them. Summary: Historically, we had a switch in the Makefiles for turning on "expensive checks". This has never been ported to the cmake build, but the (dead-ish) code is still around. This will also make it easier to turn it on in buildbots. Reviewers: chandlerc Subscribers: jyknight, mzolotukhin, RKSimon, gberry, llvm-commits Differential Revision: http://reviews.llvm.org/D19723 llvm-svn: 268050
* [GlobalOpt] Propagate operand bundlesDavid Majnemer2016-04-291-12/+46
| | | | | | | We neglected to transfer operand bundles for some transforms. These were found via inspection, I'll try to come up with some test cases. llvm-svn: 268011
* Remove doInitialization() and doFinalization() member declarations without ↵Yaron Keren2016-04-281-16/+0
| | | | | | | | definitions. Visual C++ 2015 flags this in the IDE. llvm-svn: 267919
* Add "PIE Level" metadata to module flags.Sriraman Tallam2016-04-281-0/+14
| | | | | | http://reviews.llvm.org/D19671 llvm-svn: 267911
* Fix some Clang-tidy modernize and Include What You Use warnings.Eugene Zelenko2016-04-281-6/+16
| | | | | | Differential revision: http://reviews.llvm.org/D19673 llvm-svn: 267910
* Rangify for loops, NFC.Yaron Keren2016-04-281-22/+14
| | | | llvm-svn: 267889
* NFC. Introduce Value::getPointerDerferecnceableBytesArtur Pilipenko2016-04-271-0/+34
| | | | | | | | | | Extract a part of isDereferenceableAndAlignedPointer functionality to Value::getPointerDerferecnceableBytes. Currently it's a NFC, but in future I'm going to accumulate all the logic about value dereferenceability in this function similarly to Value::getPointerAlignment function (D16144). Reviewed By: reames Differential Revision: http://reviews.llvm.org/D17572 llvm-svn: 267708
* Use DL preferred alignment for alloca in Value::getPointerAlignmentArtur Pilipenko2016-04-271-2/+7
| | | | | | | | | | Teach Value::getPointerAlignment that allocas with no explicit alignment are aligned to preferred alignment of the allocated type. Reviewed By: hfinkel Differential Revision: http://reviews.llvm.org/D17569 llvm-svn: 267689
* [CodeGenPrepare] use branch weight metadata to decide if a select should be ↵Sanjay Patel2016-04-262-22/+24
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | turned into a branch This is part of solving PR27344: https://llvm.org/bugs/show_bug.cgi?id=27344 CGP should undo the SimplifyCFG transform for the same reason that earlier patches have used this same mechanism: it's possible that passes between SimplifyCFG and CGP may be able to optimize the IR further with a select in place. For the TLI hook default, >99% taken or not taken is chosen as the default threshold for a highly predictable branch. Even the most limited HW branch predictors will be correct on this branch almost all the time, so even a massive mispredict penalty perf loss would be overcome by the win from all the times the branch was predicted correctly. As a follow-up, we could make the default target hook less conservative by using the SchedMachineModel's MispredictPenalty. Or we could just let targets override the default by implementing the hook with that and other target-specific options. Note that trying to statically determine mispredict rates for close-to-balanced profile weight data is generally impossible if the HW is sufficiently advanced. Ie, 50/50 taken/not-taken might still be 100% predictable. Finally, note that this patch as-is will not solve PR27344 because the current __builtin_unpredictable() branch weight default values are 4 and 64. A proposal to change that is in D19435. Differential Revision: http://reviews.llvm.org/D19488 llvm-svn: 267572
* Add check for "branch_weights" with prof metadataSanjay Patel2016-04-251-3/+7
| | | | | | | While we're here, fix the comment and variable names to make it clear that these are raw weights, not percentages. llvm-svn: 267491
* Reformat LLVMConstPointerNull. NFCAmaury Sechet2016-04-251-2/+1
| | | | llvm-svn: 267484
* [ThinLTO] Introduce typedef for commonly-used map type (NFC)Teresa Johnson2016-04-251-4/+2
| | | | | | | | Add a typedef for the std::map<GlobalValue::GUID, GlobalValueSummary *> map that is passed around to identify summaries for values defined in a particular module. This shortens up declarations in a variety of places. llvm-svn: 267471
* Typo. NFC.Chad Rosier2016-04-251-1/+1
| | | | llvm-svn: 267399
* Verifier: Verify that each inlinable callsite of a debug-info-bearing functionAdrian Prantl2016-04-241-0/+9
| | | | | | | | | | | | | in a debug-info-bearing function has a debug location attached to it. Failure to do so causes an "!dbg attachment points at wrong subprogram for function" assertion failure when the inliner sets up inline scope info. rdar://problem/25878916 This reaplies r267320 without changes after fixing an issue in the OpenMP IR generator in clang. llvm-svn: 267370
* [ThinLTO] Remove GlobalValueInfo class from indexTeresa Johnson2016-04-241-32/+27
| | | | | | | | | | | | | | | | Summary: Remove the GlobalValueInfo and change the ModuleSummaryIndex to directly reference summary objects. The info structure was there to support lazy parsing of the combined index summary objects, which is no longer needed and not supported. Reviewers: joker.eph Subscribers: joker.eph, llvm-commits Differential Revision: http://reviews.llvm.org/D19462 llvm-svn: 267344
* Revert "Verifier: Verify that each inlinable callsite of a ↵Adrian Prantl2016-04-241-9/+0
| | | | | | | | debug-info-bearing function" This reverts commit r267320 while investigating an OpenMP buildbot failure. llvm-svn: 267322
* Verifier: Verify that each inlinable callsite of a debug-info-bearing functionAdrian Prantl2016-04-241-0/+9
| | | | | | | | | | in a debug-info-bearing function has a debug location attached to it. Failure to do so causes an "!dbg attachment points at wrong subprogram for function" assertion failure when the inliner sets up inline scope info. rdar://problem/25878916 llvm-svn: 267320
* DebugInfo: Change DIBuilder to make distinct DIGlobalVariablesDuncan P. N. Exon Smith2016-04-231-4/+4
| | | | | | | | | | | | | | | A long overdue change to make DIGlobalVariable distinct. Much like DISubprogram definitions (changed in r246098), it isn't logical to unique DIGlobalVariable definitions from two different compile units. (Longer-term, we should also find a way to reverse the link between GlobalVariable and DIGlobalVariable, and between DIGlobalVariable and DICompileUnit, so that debug info to do with optimized-out globals disappears. Admittedly it's harder than with Function/DISubprogram, since global variables may be constant-folded and the debug info should still describe that somehow.) llvm-svn: 267301
* DebugInfo: Remove MDString-based type referencesDuncan P. N. Exon Smith2016-04-235-305/+131
| | | | | | | | | | | | | | | | | | | | | | | | Eliminate DITypeIdentifierMap and make DITypeRef a thin wrapper around DIType*. It is no longer legal to refer to a DICompositeType by its 'identifier:', and DIBuilder no longer retains all types with an 'identifier:' automatically. Aside from the bitcode upgrade, this is mainly removing logic to resolve an MDString-based reference to an actualy DIType. The commits leading up to this have made the implicit type map in DICompileUnit's 'retainedTypes:' field superfluous. This does not remove DITypeRef, DIScopeRef, DINodeRef, and DITypeRefArray, or stop using them in DI-related metadata. Although as of this commit they aren't serving a useful purpose, there are patchces under review to reuse them for CodeView support. The tests in LLVM were updated with deref-typerefs.sh, which is attached to the thread "[RFC] Lazy-loading of debug info metadata": http://lists.llvm.org/pipermail/llvm-dev/2016-April/098318.html llvm-svn: 267296
* replace duplicated static functions for profile metadata access with ↵Sanjay Patel2016-04-231-0/+18
| | | | | | BranchInst member function; NFCI llvm-svn: 267295
* BitcodeReader: Avoid referencing unresolved nodes from distinct onesDuncan P. N. Exon Smith2016-04-231-0/+10
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Each reference to an unresolved MDNode is expensive, since the RAUW support in MDNode uses a separate allocation and side map. Since a distinct MDNode doesn't require its operands on creation (unlike uniuqed nodes, there's no need to check for structural equivalence), use nullptr for any of its unresolved operands. Besides reducing the burden on MDNode maps, this can avoid allocating temporary MDNodes in the first place. We need some way to track operands. Invent DistinctMDOperandPlaceholder for this purpose, which is a Metadata subclass that holds an ID and points at its single user. DistinctMDOperandPlaceholder::replaceUseWith is just like RAUW, but its name highlights that there is only ever exactly one use. There is no support for moving (or, obviously, copying) these. Move support would be possible but expensive; leaving it unimplemented prevents user error. In the BitcodeReader I originally considered allocating on a BumpPtrAllocator and keeping a vector of pointers to them, and then I realized that std::deque implements exactly this. A couple of obvious follow-ups: - Change ValueEnumerator to emit distinct nodes first to take more advantage of this optimization. (How convenient... I think I might have a couple of patches for this.) - Change DIBuilder and its consumers (like CGDebugInfo in clang) to use something like this when constructing debug info in the first place. llvm-svn: 267270
* BitcodeReader: Use getMD/getMDOrNull helpers consistently, almost NFCDuncan P. N. Exon Smith2016-04-231-1/+0
| | | | | | | | | | The only functionality change was removing an error check from the BitcodeReader (and an assertion from DILocation::getImpl) that is already caught by Verifier::visitDILocation. The Verifier is a better place for this anyway, and being inconsistent with other subclasses of MDNode isn't serving anyone. llvm-svn: 267267
OpenPOWER on IntegriCloud