summaryrefslogtreecommitdiffstats
path: root/llvm/lib/IR
Commit message (Collapse)AuthorAgeFilesLines
* [llc] New diagnostic handlerRenato Golin2016-05-161-1/+2
| | | | | | | | | | | | | | | | | | | | | | Without a diagnostic handler installed, llc's behaviour is to exit on the first error that it encounters. This is very different from the behaviour of clang and other front ends, which try to gather as many errors as possible before exiting. This commit adds a diagnostic handler to llc, allowing it to find and report more than one error. The old behaviour is preserved under a flag (-exit-on-error). Some of the tests fail with the new diagnostic handler, so they have to use the new flag in order to run under the previous behaviour. Some of these are known bugs, others need further investigation. Ideally, we should fix the tests and remove the flag at some point in the future. Reapplied after fixing the LLDB build that was broken due to the new DiagnosticSeverity in LLVMContext.h, and fixed an UB in the new change. Patch by Diana Picus. llvm-svn: 269655
* Vector GEP - fixed a crash on InstSimplify Pass.Elena Demikhovsky2016-05-151-7/+16
| | | | | | | | Vector GEP with mixed (vector and scalar) indices failed on the InstSimplify Pass when all indices are constants. Differential revision http://reviews.llvm.org/D20149 llvm-svn: 269590
* Revert "[llc] New diagnostic handler"Renato Golin2016-05-141-2/+1
| | | | | | | | | | | | This reverts commit r269563. Even though now it passes all LLDB bots after a local fix, there's a new buildbot it fails with tests that we hadn't seen locally: http://lab.llvm.org:8011/builders/clang-x86_64-linux-selfhost-modules/builds/15647 Adding those tests to the list to investigate. llvm-svn: 269568
* [llc] New diagnostic handlerRenato Golin2016-05-141-1/+2
| | | | | | | | | | | | | | | | | | | | | | Without a diagnostic handler installed, llc's behaviour is to exit on the first error that it encounters. This is very different from the behaviour of clang and other front ends, which try to gather as many errors as possible before exiting. This commit adds a diagnostic handler to llc, allowing it to find and report more than one error. The old behaviour is preserved under a flag (-exit-on-error). Some of the tests fail with the new diagnostic handler, so they have to use the new flag in order to run under the previous behaviour. Some of these are known bugs, others need further investigation. Ideally, we should fix the tests and remove the flag at some point in the future. Reapplied after fixing the LLDB build that was broken due to the new DiagnosticSeverity in LLVMContext.h. Patch by Diana Picus. llvm-svn: 269563
* StripDebugInfo: uses isa<DbgInfoIntrinsic> instead of matching against ↵Mehdi Amini2016-05-141-9/+2
| | | | | | | | | | llvm.dbg.* (NFC) Suggested by Adrian. This is NFC right now but is more clean and robust against future potential new debug info intrinsics. From: mehdi_amini <mehdi_amini@91177308-0d34-0410-b5e6-96231b3b80d8> llvm-svn: 269540
* Revert "StripDebugInfo: uses isa<DbgInfoIntrinsic> instead of matching ↵Mehdi Amini2016-05-141-2/+9
| | | | | | | | | against llvm.dbg.* (NFC)" This reverts commit r269537, was not ready to be commited and went through by mistake From: Mehdi Amini <mehdi.amini@apple.com> llvm-svn: 269539
* StripDebugInfo: uses isa<DbgInfoIntrinsic> instead of matching against ↵Mehdi Amini2016-05-141-9/+2
| | | | | | | | | | llvm.dbg.* (NFC) Suggested by Adrian. This is NFC right now but is more clean and robust against future potential new debug info intrinsics. From: Mehdi Amini <mehdi.amini@apple.com> llvm-svn: 269537
* Rename getLargestLegalIntTypeSize to getLargestLegalIntTypeSizeInBits(). NFC.Jun Bum Lim2016-05-131-1/+1
| | | | | | | | | | | | Summary: Rename DataLayout::getLargestLegalIntTypeSize to DataLayout::getLargestLegalIntTypeSizeInBits() to prevent similar mistakes fixed in r269433. Reviewers: joker.eph, mcrosier Subscribers: mcrosier, llvm-commits Differential Revision: http://reviews.llvm.org/D20248 llvm-svn: 269456
* Revert "[llc] New diagnostic handler"Renato Golin2016-05-131-2/+1
| | | | | | | | This reverts commit r269428, as it breaks the LLDB build. We need to understand how to change LLDB in the same way as LLC before landing this again. llvm-svn: 269432
* [llc] New diagnostic handlerRenato Golin2016-05-131-1/+2
| | | | | | | | | | | | | | | | | | | Without a diagnostic handler installed, llc's behaviour is to exit on the first error that it encounters. This is very different from the behaviour of clang and other front ends, which try to gather as many errors as possible before exiting. This commit adds a diagnostic handler to llc, allowing it to find and report more than one error. The old behaviour is preserved under a flag (-exit-on-error). Some of the tests fail with the new diagnostic handler, so they have to use the new flag in order to run under the previous behaviour. Some of these are known bugs, others need further investigation. Ideally, we should fix the tests and remove the flag at some point in the future. Patch by Diana Picus. llvm-svn: 269428
* Appease MSVC with curly bracesSanjoy Das2016-05-121-1/+2
| | | | llvm-svn: 269262
* All llvm.deoptimize declarations must use the same calling conventionSanjoy Das2016-05-121-1/+25
| | | | | | | | | | | | | | | | | This new verifier rule lets us unambigously pick a calling convention when creating a new declaration for `@llvm.experimental.deoptimize.<ty>`. It is also congruent with our lowering strategy -- since all calls to `@llvm.experimental.deoptimize` are lowered to calls to `__llvm_deoptimize`, it is reasonable to enforce a unique calling convention. Some of the tests that were breaking this verifier rule have had to be split up into different .ll files. The inliner was violating this rule as well, and has been fixed to avoid producing invalid IR. llvm-svn: 269261
* 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
OpenPOWER on IntegriCloud