summaryrefslogtreecommitdiffstats
path: root/llvm/lib/Analysis
Commit message (Collapse)AuthorAgeFilesLines
* ConstantFold - silence static analyzer dyn_cast<ExtractValueInst> null ↵Simon Pilgrim2019-09-261-1/+1
| | | | | | | | dereference warning. NFCI. The static analyzer is warning about a potential null dereference, but we should be able to use cast<ExtractValueInst> directly and if not assert will fire for us. llvm-svn: 372993
* [LoopInfo] Limit the iterations to check whether a loop has dedicated exitsWei Mi2019-09-261-0/+7
| | | | | | | | | | | | | | for extreme large case. We had a case that a single loop which has 4000 exits and the average number of predecessors of each exit is > 1000, and we found compiling the case spent a significant amount of time on checking whether a loop has dedicated exits. This patch adds a limit for the iterations to the check. With the patch, the time to compile our testcase reduced from 1000s to 200s (clang release build). Differential Revision: https://reviews.llvm.org/D67359 llvm-svn: 372990
* Remove local shadow constant. NFCI.Simon Pilgrim2019-09-261-2/+0
| | | | | | ValueTracking.cpp already has a local static MaxDepth = 6 constant - this one seems to have been missed when rL124183 landed. llvm-svn: 372964
* [ValueTracking] Silence static analyzer dyn_cast<Operator> null dereference ↵Simon Pilgrim2019-09-261-225/+228
| | | | | | | | warnings. NFCI. The static analyzer is warning about a potential null dereferences, but since the pointer is only used in a switch statement for Operator::getOpcode() (with an empty default) then its easiest just to wrap this in a null test as the dyn_cast might return null here. llvm-svn: 372962
* [ConstantFolding] Use FoldBitCast correctlyKeno Fischer2019-09-261-2/+20
| | | | | | | | | | | | | Previously we might attempt to use a BitCast to turn bits into vectors of pointers, but that requires an inttoptr cast to be legal. Add an assertion to detect the formation of illegal bitcast attempts early (in the tests, we often constant-fold away the result before getting to this assertion check), while being careful to still handle the early-return conditions without adding extra complexity in the result. Patch by Jameson Nash <jameson@juliacomputing.com>. Differential Revision: https://reviews.llvm.org/D65057 llvm-svn: 372940
* [MemorySSA] Avoid adding Phis in the presence of unreachable blocks.Alina Sbirlea2019-09-251-45/+57
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: If a block has all incoming values with the same MemoryAccess (ignoring incoming values from unreachable blocks), then use that incoming MemoryAccess and do not create a Phi in the first place. Revert IDF work-around added in rL372673; it should not be required unless the Def inserted is the first in its block. The patch also cleans up a series of tests, added during the many iterations on insertDef. The patch also fixes PR43438. The same issue that occurs in insertDef with "adding phis, hence the IDF of Phis is needed", can also occur in fixupDefs: the `getPreviousRecursive` call only adds Phis walking on the predecessor edges, which means there may be the case of a Phi added walking the CFG "backwards" which triggers the needs for an additional Phi in successor blocks. Such Phis are added during fixupDefs only in the presence of unreachable blocks. Hence this highlights the need to avoid adding Phis in blocks with unreachable predecessors in the first place. Reviewers: george.burgess.iv Subscribers: Prazek, sanjoy.google, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D67995 llvm-svn: 372932
* [InstSimplify] Handle more 'A </>/>=/<= B &&/|| (A - B) !=/== 0' patterns ↵Roman Lebedev2019-09-251-0/+12
| | | | | | | | | | | (PR43251) https://rise4fun.com/Alive/sl9s https://rise4fun.com/Alive/2plN https://bugs.llvm.org/show_bug.cgi?id=43251 llvm-svn: 372928
* [InstSimplify] Match 1.0 and 0.0 for both operands in SimplifyFMAMulFlorian Hahn2019-09-251-0/+8
| | | | | | | | | | | | | | | | | | Because we do not constant fold multiplications in SimplifyFMAMul, we match 1.0 and 0.0 for both operands, as multiplying by them is guaranteed to produce an exact result (if it is allowed to do so). Note that it is not enough to just swap the operands to ensure a constant is on the RHS, as we want to also cover the case with 2 constants. Reviewers: lebedev.ri, spatel, reames, scanon Reviewed By: lebedev.ri, reames Differential Revision: https://reviews.llvm.org/D67553 llvm-svn: 372915
* [InstCombine] Limit FMul constant folding for fma simplifications.Florian Hahn2019-09-251-9/+20
| | | | | | | | | | | | | | | | | As @reames pointed out post-commit, rL371518 adds additional rounding in some cases, when doing constant folding of the multiplication. This breaks a guarantee llvm.fma makes and must be avoided. This patch reapplies rL371518, but splits off the simplifications not requiring rounding from SimplifFMulInst as SimplifyFMAFMul. Reviewers: spatel, lebedev.ri, reames, scanon Reviewed By: reames Differential Revision: https://reviews.llvm.org/D67434 llvm-svn: 372899
* [PatternMatch] Make m_Br more flexible, add matchers for BB values.Florian Hahn2019-09-251-2/+1
| | | | | | | | | | | | | | | | | | | | | Currently m_Br only takes references to BasicBlock*, which limits its flexibility. For example, you have to declare a variable, even if you ignore the result or you have to have additional checks to make sure the matched BB matches an expected one. This patch adds m_BasicBlock and m_SpecificBB matchers, which can be used like the existing matchers for constants or values. I also had a look at the existing uses and updated a few. IMO it makes the code a bit more explicit. Reviewers: spatel, craig.topper, RKSimon, majnemer, lebedev.ri Reviewed By: lebedev.ri Differential Revision: https://reviews.llvm.org/D68013 llvm-svn: 372885
* [IR] allow fast-math-flags on phi of FP values (2nd try)Sanjay Patel2019-09-251-1/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The changes here are based on the corresponding diffs for allowing FMF on 'select': D61917 <https://reviews.llvm.org/D61917> As discussed there, we want to have fast-math-flags be a property of an FP value because the alternative (having them on things like fcmp) leads to logical inconsistency such as: https://bugs.llvm.org/show_bug.cgi?id=38086 The earlier patch for select made almost no practical difference because most unoptimized conditional code begins life as a phi (based on what I see in clang). Similarly, I don't expect this patch to do much on its own either because SimplifyCFG promptly drops the flags when converting to select on a minimal example like: https://bugs.llvm.org/show_bug.cgi?id=39535 But once we have this plumbing in place, we should be able to wire up the FMF propagation and start solving cases like that. The change to RecurrenceDescriptor::AddReductionVar() is required to prevent a regression in a LoopVectorize test. We are intersecting the FMF of any FPMathOperator there, so if a phi is not properly annotated, new math instructions may not be either. Once we fix the propagation in SimplifyCFG, it may be safe to remove that hack. Differential Revision: https://reviews.llvm.org/D67564 llvm-svn: 372878
* Revert [IR] allow fast-math-flags on phi of FP valuesSanjay Patel2019-09-251-2/+1
| | | | | | This reverts r372866 (git commit dec03223a97af0e4dfcb23da55c0f7f8c9b62d00) llvm-svn: 372868
* [IR] allow fast-math-flags on phi of FP valuesSanjay Patel2019-09-251-1/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The changes here are based on the corresponding diffs for allowing FMF on 'select': D61917 As discussed there, we want to have fast-math-flags be a property of an FP value because the alternative (having them on things like fcmp) leads to logical inconsistency such as: https://bugs.llvm.org/show_bug.cgi?id=38086 The earlier patch for select made almost no practical difference because most unoptimized conditional code begins life as a phi (based on what I see in clang). Similarly, I don't expect this patch to do much on its own either because SimplifyCFG promptly drops the flags when converting to select on a minimal example like: https://bugs.llvm.org/show_bug.cgi?id=39535 But once we have this plumbing in place, we should be able to wire up the FMF propagation and start solving cases like that. The change to RecurrenceDescriptor::AddReductionVar() is required to prevent a regression in a LoopVectorize test. We are intersecting the FMF of any FPMathOperator there, so if a phi is not properly annotated, new math instructions may not be either. Once we fix the propagation in SimplifyCFG, it may be safe to remove that hack. Differential Revision: https://reviews.llvm.org/D67564 llvm-svn: 372866
* [SCEV] Disable canonical expansion for non-affine addrecs.Artur Pilipenko2019-09-241-1/+12
| | | | | | | | | | Reviewed By: apilipenko Differential Revision: https://reviews.llvm.org/D65276 Patch by Evgeniy Brevnov (ybrevnov@azul.com) llvm-svn: 372789
* [PGO][PGSO] ProfileSummary changes.Hiroshi Yamauchi2019-09-241-0/+67
| | | | | | | | | | (Split of off D67120) ProfileSummary changes for profile guided size optimization. Differential Revision: https://reviews.llvm.org/D67377 llvm-svn: 372783
* [MemorySSA] Update Phi insertion.Alina Sbirlea2019-09-231-43/+39
| | | | | | | | | | | | | | | | | | | | | | Summary: MemoryPhis may be needed following a Def insertion inthe IDF of all the new accesses added (phis + potentially a def). Ensure this also occurs when only the new MemoryPhis are the defining accesses. Note: The need for computing IDF here is because of new Phis added with edges incoming from unreachable code, Phis that had previously been simplified. The preferred solution is to not reintroduce such Phis. This patch is the needed fix while working on the preferred solution. Reviewers: george.burgess.iv Subscribers: Prazek, sanjoy.google, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D67927 llvm-svn: 372673
* [ValueTracking] Fix uninitialized variable warnings in matchSelectPattern ↵Simon Pilgrim2019-09-231-5/+6
| | | | | | | | | | const wrapper. NFCI. Static analyzer complains about const_cast uninitialized variables, we should explicitly set these to null. Ideally that const wrapper would go away though....... llvm-svn: 372603
* [InstSimplify] simplifyUnsignedRangeCheck(): X >= Y && Y == 0 --> Y == 0Roman Lebedev2019-09-211-4/+3
| | | | | | https://rise4fun.com/Alive/v9Y4 llvm-svn: 372491
* [InstSimplify][NFC] Reorganize simplifyUnsignedRangeCheck() to emphasize ↵Roman Lebedev2019-09-211-8/+11
| | | | | | | | and/or symmetry Only a single `X >= Y && Y == 0 --> Y == 0` fold appears to be missing. llvm-svn: 372490
* [Inliner] Remove incorrect early exit during switch cost computationTeresa Johnson2019-09-201-13/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: The CallAnalyzer::visitSwitchInst has an early exit when the estimated lower bound of the switch cost will put the overall cost of the inline above the threshold. However, this code is not correctly estimating the lower bound for switches that can be transformed into bit tests, leading to unnecessary lost inlines, and also differing behavior with optimization remarks enabled. First, the early exit is controlled by whether ComputeFullInlineCost is enabled or not, and that in turn is disabled by default but enabled when enabling -pass-remarks=missed. This by itself wouldn't lead to a problem, except that as described below, the lower bound can be above the real lower bound, so we can sometimes get different inline decisions with inline remarks enabled, which is problematic. The early exit was added in along with a new switch cost model in D31085. The reason why this early exit was added is due to a concern one reviewer raised about compile time for large switches: https://reviews.llvm.org/D31085?id=94559#inline-276200 However, the code just below there calls getEstimatedNumberOfCaseClusters, which in turn immediately calls BasicTTIImpl getEstimatedNumberOfCaseClusters, which in the worst case does a linear scan of the cases to get the high and low values. The bit test handling in particular is guarded by whether the number of cases fits into the max bit width. There is no suggestion that anyone measured a compile time issue, it appears to be theoretical. The problem is that the reviewer's comment about the lower bound calculation is incorrect, specifically in the case of a switch that can be lowered to a bit test. This isn't followed up on the comment thread, but the author does add a FIXME to that effect above the early exit added when they subsequently revised the patch. As a result, we were incorrectly early exiting and not inlining functions with switch statements that would be lowered to bit tests in cases where we were nearing the threshold. Combined with the fact that this early exit was skipped with opt remarks enabled, this caused different inlining decisions to be made when -pass-remarks=missed is enabled to debug the missing inline. Remove the early exit for the above reasons. I also copied over an existing AArch64 inlining test to X86, and adjusted the threshold so that the bit test inline only occurs with the fix in this patch. Reviewers: davidxl Subscribers: eraman, kristof.beyls, haicheng, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D67716 llvm-svn: 372440
* [Analysis] Allow -scalar-evolution-max-iterations more than onceShoaib Meenai2019-09-191-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | At present, `-scalar-evolution-max-iterations` is a `cl::Optional` option, which means it demands to be passed exactly zero or one times. Our build system makes it pretty tricky to guarantee this. We often accidentally pass the flag more than once (but always with the same value) which results in an error, after which compilation fails: ``` clang (LLVM option parsing): for the -scalar-evolution-max-iterations option: may only occur zero or one times! ``` It seems reasonable to allow -scalar-evolution-max-iterations to be passed more than once. Quoting the [[ http://llvm.org/docs/CommandLine.html#controlling-the-number-of-occurrences-required-and-allowed | documentation ]]: > The cl::ZeroOrMore modifier ... indicates that your program will allow the option to be specified zero or more times. > ... > If an option is specified multiple times for an option of the cl::opt class, only the last value will be retained. Original patch by: Enrico Bern Hardy Tanuwidjaja <etanuwid@fb.com> Differential Revision: https://reviews.llvm.org/D67512 llvm-svn: 372346
* [SVFS] Vector Function ABI demangling.Francesco Petrogalli2019-09-192-0/+419
| | | | | | | | | | | | | | | | This patch implements the demangling functionality as described in the Vector Function ABI. This patch will be used to implement the SearchVectorFunctionSystem (SVFS) as described in the RFC: http://lists.llvm.org/pipermail/llvm-dev/2019-June/133484.html A fuzzer is added to test the demangling utility. Patch by Sumedh Arani <sumedh.arani@arm.com> Differential revision: https://reviews.llvm.org/D66024 llvm-svn: 372343
* Data Dependence Graph BasicsBardia Mahjour2019-09-183-0/+383
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: This is the first patch in a series of patches that will implement data dependence graph in LLVM. Many of the ideas used in this implementation are based on the following paper: D. J. Kuck, R. H. Kuhn, D. A. Padua, B. Leasure, and M. Wolfe (1981). DEPENDENCE GRAPHS AND COMPILER OPTIMIZATIONS. This patch contains support for a basic DDGs containing only atomic nodes (one node for each instruction). The edges are two fold: def-use edges and memory-dependence edges. The implementation takes a list of basic-blocks and only considers dependencies among instructions in those basic blocks. Any dependencies coming into or going out of instructions that do not belong to those basic blocks are ignored. The algorithm for building the graph involves the following steps in order: 1. For each instruction in the range of basic blocks to consider, create an atomic node in the resulting graph. 2. For each node in the graph establish def-use edges to/from other nodes in the graph. 3. For each pair of nodes containing memory instruction(s) create memory edges between them. This part of the algorithm goes through the instructions in lexicographical order and creates edges in reverse order if the sink of the dependence occurs before the source of it. Authored By: bmahjour Reviewer: Meinersbur, fhahn, myhsu, xtian, dmgreen, kbarton, jdoerfert Reviewed By: Meinersbur, fhahn, myhsu Subscribers: ychen, arphaman, simoll, a.elovikov, mgorny, hiraditya, jfb, wuzish, llvm-commits, jsji, Whitney, etiotto Tag: #llvm Differential Revision: https://reviews.llvm.org/D65350 llvm-svn: 372238
* [SDA] Don't stop divergence propagation at the IPD.Jay Foad2019-09-181-35/+26
| | | | | | | | | | | | | | | | | | | Summary: This fixes B42473 and B42706. This patch makes the SDA propagate branch divergence until the end of the RPO traversal. Before, the SyncDependenceAnalysis propagated divergence only until the IPD in rpo order. RPO is incompatible with post dominance in the presence of loops. This made the SDA crash because blocks were missed in the propagation. Reviewers: foad, nhaehnle Reviewed By: foad Subscribers: jvesely, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D65274 llvm-svn: 372223
* Revert "Data Dependence Graph Basics"Bardia Mahjour2019-09-173-383/+0
| | | | | | This reverts commit c98ec60993a7aa65073692b62f6d728b36e68ccd, which broke the sphinx-docs build. llvm-svn: 372168
* Data Dependence Graph BasicsBardia Mahjour2019-09-173-0/+383
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: This is the first patch in a series of patches that will implement data dependence graph in LLVM. Many of the ideas used in this implementation are based on the following paper: D. J. Kuck, R. H. Kuhn, D. A. Padua, B. Leasure, and M. Wolfe (1981). DEPENDENCE GRAPHS AND COMPILER OPTIMIZATIONS. This patch contains support for a basic DDGs containing only atomic nodes (one node for each instruction). The edges are two fold: def-use edges and memory-dependence edges. The implementation takes a list of basic-blocks and only considers dependencies among instructions in those basic blocks. Any dependencies coming into or going out of instructions that do not belong to those basic blocks are ignored. The algorithm for building the graph involves the following steps in order: 1. For each instruction in the range of basic blocks to consider, create an atomic node in the resulting graph. 2. For each node in the graph establish def-use edges to/from other nodes in the graph. 3. For each pair of nodes containing memory instruction(s) create memory edges between them. This part of the algorithm goes through the instructions in lexicographical order and creates edges in reverse order if the sink of the dependence occurs before the source of it. Authored By: bmahjour Reviewer: Meinersbur, fhahn, myhsu, xtian, dmgreen, kbarton, jdoerfert Reviewed By: Meinersbur, fhahn, myhsu Subscribers: ychen, arphaman, simoll, a.elovikov, mgorny, hiraditya, jfb, wuzish, llvm-commits, jsji, Whitney, etiotto Tag: #llvm Differential Revision: https://reviews.llvm.org/D65350 llvm-svn: 372162
* [MemorySSA] Fix phi insertion when inserting a def.Alina Sbirlea2019-09-171-0/+3
| | | | | | | | | | | | | | | | | | | Summary: When inserting a Def, the current algorithm is walking edges backward and inserting new Phis where needed. There may be additional Phis needed in the IDF of the newly inserted Def and Phis. Adding Phis in the IDF of the Def was added ina previous patch, but we may also need other Phis in the IDF of the newly added Phis. Reviewers: george.burgess.iv Subscribers: Prazek, sanjoy.google, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D67637 llvm-svn: 372138
* [MemorySSA] Update MSSA for non-conventional AA.Alina Sbirlea2019-09-171-1/+7
| | | | | | | | | | | | | | | | | | | Summary: Regularly when moving an instruction that may not read or write memory, the instruction is not modelled in MSSA, so not action is necessary. For a non-conventional AA pipeline, MSSA needs to explicitly check when creating accesses, so as to not model instructions that may not read and write memory. Reviewers: george.burgess.iv Subscribers: Prazek, sanjoy.google, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D67562 llvm-svn: 372137
* InterleavedAccessInfo - Don't dereference a dyn_cast result. NFCI.Simon Pilgrim2019-09-171-1/+1
| | | | llvm-svn: 372117
* [InstCombine] Annotate strdup with deref_or_nullDavid Bolvansky2019-09-171-0/+7
| | | | llvm-svn: 372098
* [NFC] remove unused functionsGuillaume Chatelet2019-09-161-8/+0
| | | | | | | | | | | | Reviewers: courbet Subscribers: hiraditya, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D67616 llvm-svn: 371994
* [InstSimplify] simplifyUnsignedRangeCheck(): handle few tautological cases ↵Roman Lebedev2019-09-141-16/+37
| | | | | | | | | | | | | | | | | | | | | | | | | | (PR43251) Summary: This is split off from D67356, since these cases produce a constant, no real need to keep them in instcombine. Alive proofs: https://rise4fun.com/Alive/u7Fk https://rise4fun.com/Alive/4lV https://bugs.llvm.org/show_bug.cgi?id=43251 Reviewers: spatel, nikic, xbolva00 Reviewed By: spatel Subscribers: hiraditya, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D67498 llvm-svn: 371921
* [SCEV] Add smin support to getRangeRefPhilip Reames2019-09-121-0/+8
| | | | | | | | We were failing to compute trip counts (both exact and maximum) for any loop which involved a comparison against either an umin or smin. It looks like this simply got missed when we added smin/umin to SCEV. (Note: umin was submitted separately earlier today. Turned out two folks hit this at the same time.) Differential Revision: https://reviews.llvm.org/D67514 llvm-svn: 371776
* [ConstantFolding] Expand folding of some library functionsEvandro Menezes2019-09-121-3/+22
| | | | | | | | | Expanding the folding of `nearbyint()`, `rint()` and `trunc()` to library functions, in addition to the current support for intrinsics. Differential revision: https://reviews.llvm.org/D67468 llvm-svn: 371774
* [SCEV] Support SCEVUMinExpr in getRangeRef.Florian Hahn2019-09-121-0/+8
| | | | | | | | | | | | | This patch adds support for SCEVUMinExpr to getRangeRef, similar to the support for SCEVUMaxExpr. Reviewers: sanjoy.google, efriedma, reames, nikic Reviewed By: sanjoy.google Differential Revision: https://reviews.llvm.org/D67177 llvm-svn: 371768
* [LICM/AST] Check if the AliasAny set is removed from the tracker.Alina Sbirlea2019-09-121-2/+10
| | | | | | | | | | | | | | | | Summary: Resolves PR38513. Credit to @bjope for debugging this. Reviewers: hfinkel, uabelho, bjope Subscribers: sanjoy.google, bjope, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D67417 llvm-svn: 371752
* [LV] Support invariant addresses in speculation logicPhilip Reames2019-09-121-10/+18
| | | | | | | | | | Implement a TODO from rL371452, and handle loop invariant addresses in predicated blocks. If we can prove that the load is safe to speculate into the header, then we can avoid using a masked.load in favour of a normal load. This is mostly about vectorization robustness. In the common case, it's generally expected that LICM/LoadStorePromotion would have eliminated such loads entirely. Differential Revision: https://reviews.llvm.org/D67372 llvm-svn: 371745
* [ConstProp] allow folding for fma that produces NaNSanjay Patel2019-09-121-7/+3
| | | | | | | | | | | | | | | | | | | | Folding for fma/fmuladd was added here: rL202914 ...and as seen in existing/unchanged tests, that works to propagate NaN if it's already an input, but we should fold an fma() that creates NaN too. From IEEE-754-2008 7.2 "Invalid Operation", there are 2 clauses that apply to fma, so I added tests for those patterns: c) fusedMultiplyAdd: fusedMultiplyAdd(0, ∞, c) or fusedMultiplyAdd(∞, 0, c) unless c is a quiet NaN; if c is a quiet NaN then it is implementation defined whether the invalid operation exception is signaled d) addition or subtraction or fusedMultiplyAdd: magnitude subtraction of infinities, such as: addition(+∞, −∞) Differential Revision: https://reviews.llvm.org/D67446 llvm-svn: 371735
* [InstSimplify] simplifyUnsignedRangeCheck(): handle more cases (PR43251)Roman Lebedev2019-09-121-0/+20
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: I don't have a direct motivational case for this, but it would be good to have this for completeness/symmetry. This pattern is basically the motivational pattern from https://bugs.llvm.org/show_bug.cgi?id=43251 but with different predicate that requires that the offset is non-zero. The completeness bit comes from the fact that a similar pattern (offset != zero) will be needed for https://bugs.llvm.org/show_bug.cgi?id=43259, so it'd seem to be good to not overlook very similar patterns.. Proofs: https://rise4fun.com/Alive/21b Also, there is something odd with `isKnownNonZero()`, if the non-zero knowledge was specified as an assumption, it didn't pick it up (PR43267) Reviewers: spatel, nikic, xbolva00 Reviewed By: spatel Subscribers: hiraditya, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D67411 llvm-svn: 371718
* [ConstantFolding] Refactor math functions to use LLVM ones (NFC)Evandro Menezes2019-09-111-37/+42
| | | | | | | | | When possible, replace calls to library routines on the host with equivalent ones in LLVM. Differential revision: https://reviews.llvm.org/D67459 llvm-svn: 371677
* [InstSimplify] Pass SimplifyQuery into simplifyUnsignedRangeCheck() and use ↵Roman Lebedev2019-09-111-17/+15
| | | | | | | | | | it for isKnownNonZero() This was actually the original intention in D67332, but i messed up and forgot about it. This patch was originally part of D67411, but precommitting this. llvm-svn: 371630
* [TLI][AMDGPU] AMDPAL does not have library functionsTim Renouf2019-09-111-12/+2
| | | | | | | | | | | Configure TLI to say that r600/amdgpu does not have any library functions, such that InstCombine does not do anything like turn sin/cos into the library function @tan with sufficient fast math flags. Differential Revision: https://reviews.llvm.org/D67406 Change-Id: I02f907d3e64832117ea9800e9f9285282856e5df llvm-svn: 371592
* [MemorySSA] Do not create memoryaccesses for debug info intrinsics.Alina Sbirlea2019-09-101-2/+9
| | | | | | | | | | | | | | | | Summary: Do not model debuginfo intrinsics in MemorySSA. Regularly these are non-memory modifying instructions. With -disable-basicaa, they were being modelled as Defs. Reviewers: george.burgess.iv Subscribers: aprantl, Prazek, sanjoy.google, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D67307 llvm-svn: 371565
* [Loads] Move generic code out of vectorizer into a location it might be ↵Philip Reames2019-09-101-0/+50
| | | | | | reused [NFC] llvm-svn: 371558
* [ValueTracking] Factor our common speculation suppression logic [NFC]Philip Reames2019-09-101-6/+13
| | | | | | Expose a utility function so that all places which want to suppress speculation (when otherwise legal) due to ordering and/or sanitizer interaction can do so. llvm-svn: 371556
* [BPI] Adjust the probability for floating point unordered comparisonGuozhi Wei2019-09-101-2/+14
| | | | | | | | Since NaN is very rare in normal programs, so the probability for floating point unordered comparison should be extremely small. Current probability is 3/8, it is too large, this patch changes it to a tiny number. Differential Revision: https://reviews.llvm.org/D65303 llvm-svn: 371541
* [InstSimplify] simplifyUnsignedRangeCheck(): if we know that X != 0, handle ↵Roman Lebedev2019-09-081-9/+24
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | more cases (PR43246) Summary: This is motivated by D67122 sanitizer check enhancement. That patch seemingly worsens `-fsanitize=pointer-overflow` overhead from 25% to 50%, which strongly implies missing folds. In this particular case, given ``` char* test(char& base, unsigned long offset) { return &base + offset; } ``` it will end up producing something like https://godbolt.org/z/LK5-iH which after optimizations reduces down to roughly ``` define i1 @t0(i8* nonnull %base, i64 %offset) { %base_int = ptrtoint i8* %base to i64 %adjusted = add i64 %base_int, %offset %non_null_after_adjustment = icmp ne i64 %adjusted, 0 %no_overflow_during_adjustment = icmp uge i64 %adjusted, %base_int %res = and i1 %non_null_after_adjustment, %no_overflow_during_adjustment ret i1 %res } ``` Without D67122 there was no `%non_null_after_adjustment`, and in this particular case we can get rid of the overhead: Here we add some offset to a non-null pointer, and check that the result does not overflow and is not a null pointer. But since the base pointer is already non-null, and we check for overflow, that overflow check will already catch the null pointer, so the separate null check is redundant and can be dropped. Alive proofs: https://rise4fun.com/Alive/WRzq There are more patterns of "unsigned-add-with-overflow", they are not handled here, but this is the main pattern, that we currently consider canonical, so it makes sense to handle it. https://bugs.llvm.org/show_bug.cgi?id=43246 Reviewers: spatel, nikic, vsk Reviewed By: spatel Subscribers: hiraditya, llvm-commits, reames Tags: #llvm Differential Revision: https://reviews.llvm.org/D67332 llvm-svn: 371349
* [Intrinsic] Add the llvm.umul.fix.sat intrinsicBjorn Pettersson2019-09-071-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: Add an intrinsic that takes 2 unsigned integers with the scale of them provided as the third argument and performs fixed point multiplication on them. The result is saturated and clamped between the largest and smallest representable values of the first 2 operands. This is a part of implementing fixed point arithmetic in clang where some of the more complex operations will be implemented as intrinsics. Patch by: leonardchan, bjope Reviewers: RKSimon, craig.topper, bevinh, leonardchan, lebedev.ri, spatel Reviewed By: leonardchan Subscribers: ychen, wuzish, nemanjai, MaskRay, jsji, jdoerfert, Ka-Ka, hiraditya, rjmccall, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D57836 llvm-svn: 371308
* [LVI] Look through extractvalue of insertvalueNikita Popov2019-09-071-0/+15
| | | | | | | | | | | | | | | | | | | | | | | | | This addresses the issue mentioned on D19867. When we simplify with.overflow instructions in CVP, we leave behind extractvalue of insertvalue sequences that LVI no longer understands. This means that we can not simplify any instructions based on the with.overflow anymore (until some over pass like InstCombine cleans them up). This patch extends LVI extractvalue handling by calling SimplifyExtractValueInst (which doesn't do anything more than constant folding + looking through insertvalue) and using the block value of the simplification. A possible alternative would be to do something similar to SimplifyIndVars, where we instead directly try to replace extractvalue users of the with.overflow. This would need some additional structural changes to CVP, as it's currently not legal to remove anything but the current instruction -- we'd have to introduce a worklist with instructions scheduled for deletion or similar. Differential Revision: https://reviews.llvm.org/D67035 llvm-svn: 371306
* Change TargetLibraryInfo analysis passes to always require FunctionTeresa Johnson2019-09-0716-55/+97
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: This is the first change to enable the TLI to be built per-function so that -fno-builtin* handling can be migrated to use function attributes. See discussion on D61634 for background. This is an enabler for fixing handling of these options for LTO, for example. This change should not affect behavior, as the provided function is not yet used to build a specifically per-function TLI, but rather enables that migration. Most of the changes were very mechanical, e.g. passing a Function to the legacy analysis pass's getTLI interface, or in Module level cases, adding a callback. This is similar to the way the per-function TTI analysis works. There was one place where we were looking for builtins but not in the context of a specific function. See FindCXAAtExit in lib/Transforms/IPO/GlobalOpt.cpp. I'm somewhat concerned my workaround could provide the wrong behavior in some corner cases. Suggestions welcome. Reviewers: chandlerc, hfinkel Subscribers: arsenm, dschuff, jvesely, nhaehnle, mehdi_amini, javed.absar, sbc100, jgravelle-google, eraman, aheejin, steven_wu, george.burgess.iv, dexonsmith, jfb, asbirlea, gchatelet, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D66428 llvm-svn: 371284
OpenPOWER on IntegriCloud