summaryrefslogtreecommitdiffstats
path: root/llvm/lib/Analysis
Commit message (Collapse)AuthorAgeFilesLines
...
* Remove `CallSite` from the CodeMetrics analysis, moving it to the newChandler Carruth2019-02-111-7/+4
| | | | | | `CallBase` and simpler APIs therein. llvm-svn: 353673
* [CallSite removal] Port InstSimplify over to use `CallBase` both in itsChandler Carruth2019-02-111-19/+17
| | | | | | | | interface and implementation. Port code with: `cast<CallBase>(CS.getInstruction())`. llvm-svn: 353662
* [CallSite removal] Migrate ConstantFolding APIs and implementation toChandler Carruth2019-02-113-30/+35
| | | | | | | | | `CallBase`. Users have been updated. You can see how to update any out-of-tree usages: pass `cast<CallBase>(CS.getInstruction())`. llvm-svn: 353661
* Implementation of asm-goto support in LLVMCraig Topper2019-02-081-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | This patch accompanies the RFC posted here: http://lists.llvm.org/pipermail/llvm-dev/2018-October/127239.html This patch adds a new CallBr IR instruction to support asm-goto inline assembly like gcc as used by the linux kernel. This instruction is both a call instruction and a terminator instruction with multiple successors. Only inline assembly usage is supported today. This also adds a new INLINEASM_BR opcode to SelectionDAG and MachineIR to represent an INLINEASM block that is also considered a terminator instruction. There will likely be more bug fixes and optimizations to follow this, but we felt it had reached a point where we would like to switch to an incremental development model. Patch by Craig Topper, Alexander Ivchenko, Mikhail Dvoretckii Differential Revision: https://reviews.llvm.org/D53765 llvm-svn: 353563
* [CodeExtractor] Update function's assumption cache after extracting blocks ↵Sergey Dmitriev2019-02-081-2/+26
| | | | | | | | | | | | | | | | | | from it Summary: Assumption cache's self-updating mechanism does not correctly handle the case when blocks are extracted from the function by the CodeExtractor. As a result function's assumption cache may have stale references to the llvm.assume calls that were moved to the outlined function. This patch fixes this problem by removing extracted llvm.assume calls from the function’s assumption cache. Reviewers: hfinkel, vsk, fhahn, davidxl, sanjoy Reviewed By: hfinkel, vsk Subscribers: llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D57215 llvm-svn: 353500
* [LSR] Generate cross iteration indexesSam Parker2019-02-071-0/+4
| | | | | | | | | | | | | | Modify GenerateConstantOffsetsImpl to create offsets that can be used by indexed addressing modes. If formulae can be generated which result in the constant offset being the same size as the recurrence, we can generate a pre-indexed access. This allows the pointer to be updated via the single pre-indexed access so that (hopefully) no add/subs are required to update it for the next iteration. For small cores, this can significantly improve performance DSP-like loops. Differential Revision: https://reviews.llvm.org/D55373 llvm-svn: 353403
* [LICM/MSSA] Add promotion to scalars by building an AliasSetTracker with ↵Alina Sbirlea2019-02-061-0/+11
| | | | | | | | | | | | | | | | | | | | | | | | MemorySSA. Summary: Experimentally we found that promotion to scalars carries less benefits than sinking and hoisting in LICM. When using MemorySSA, we build an AliasSetTracker on demand in order to reuse the current infrastructure. We only build it if less than AccessCapForMSSAPromotion exist in the loop, a cap that is by default set to 250. This value ensures there are no runtime regressions, and there are small compile time gains for pathological cases. A much lower value (20) was found to yield a single regression in the llvm-test-suite and much higher benefits for compile times. Conservatively we set the current cap to a high value, but we will explore lowering it when MemorySSA is enabled by default. Reviewers: sanjoy, chandlerc Subscribers: nemanjai, jlebar, Prazek, george.burgess.iv, jfb, jsji, llvm-commits Differential Revision: https://reviews.llvm.org/D56625 llvm-svn: 353339
* [AliasSetTracker] Pass MustAlias to addPointer more often.Alina Sbirlea2019-02-061-24/+36
| | | | | | | | | | | | | | | Summary: Pass the alias info to addPointer when available. Will save an alias() call for must sets when adding a known Must or May alias. [Part of a series of cleanup patches] Reviewers: reames, mkazantsev Subscribers: sanjoy, jlebar, llvm-commits Differential Revision: https://reviews.llvm.org/D56613 llvm-svn: 353335
* [AliasSetTracker] Minor style tweak to avoid a variable w/two distinct live ↵Philip Reames2019-02-061-4/+2
| | | | | | ranges [NFC] llvm-svn: 353267
* Move DomTreeUpdater from IR to AnalysisRichard Trieu2019-02-063-1/+530
| | | | | | | | DomTreeUpdater depends on headers from Analysis, but is in IR. This is a layering violation since Analysis depends on IR. Relocate this code from IR to Analysis to fix the layering violation. llvm-svn: 353265
* [BasicAA] Cache nonEscapingLocalObjects for alias() calls.Alina Sbirlea2019-02-051-7/+27
| | | | | | | | | | | | | | | | | | | | | | | | | Summary: Use a small cache for Values tested by nonEscapingLocalObject(). Since the calls to PointerMayBeCaptured are fairly expensive, this saves a good amount of compile time for anything relying heavily on BasicAA.alias() calls. This uses the same approach as the AliasCache, i.e. the cache is reset after each alias() call. The cache is not used or updated by modRefInfo calls since it's harder to know when to reset the cache. Testcases that show improvements with this patch are too large to include. Example compile time improvement: 7s to 6s. Reviewers: chandlerc, sunfish Subscribers: sanjoy, jlebar, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D57627 llvm-svn: 353245
* [TargetLibraryInfo] Regroup run time functions for Windows (NFC)Evandro Menezes2019-02-051-38/+37
| | | | | | Regroup supported and unsupported functions by precision and C standard. llvm-svn: 353213
* [NFC] fix trivial typos in commentsHiroshi Inoue2019-02-058-13/+13
| | | | llvm-svn: 353147
* Revert "[PATCH] [TargetLibraryInfo] Update run time support for Windows"Evandro Menezes2019-02-041-59/+53
| | | | | | This reverts accidental commit ff5527718d5d3b9966f6e8948866c0dc15ffcf3c. llvm-svn: 353118
* [PATCH] [TargetLibraryInfo] Update run time support for WindowsEvandro Menezes2019-02-041-53/+59
| | | | | | | | | | | | | It seems that the run time for Windows has changed and supports more math functions than before. Since LLVM requires at least VS2015, I assume that this is the run time that would be redistributed with programs built with Clang. Thus, I based this update on the header file `math.h` that accompanies it. This patch addresses the PR40541. Unfortunately, I have no access to a Windows development environment to validate it. llvm-svn: 353114
* Adjust cardinality of internal inliner thresholdsDavid Callahan2019-02-041-4/+4
| | | | | | | | | | | | | | | | | | | Summary: While compiling openJDK11 (also other workloads), some make files would pass both CFLAGS and LDFLAGS at link step ; resulting in duplicate options on the command line when one is using LTO and trying to influence the inliner. Most of the internal flags are ZeroOrMore, this diff changes the remaining ones. Reviewers: david2050, twoh, modocache Reviewed By: twoh Subscribers: mehdi_amini, dexonsmith, eraman, haicheng, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D57537 Patch by: Abdoul-Kader Keita llvm-svn: 353071
* [SCEV] Do not bother creating separate SCEVUnknown for unreachable nodesMax Kazantsev2019-02-041-1/+1
| | | | | | | | | | | Currently, SCEV creates SCEVUnknown for every node of unreachable code. If we have a huge amounts of such code, we will be littering SE with these nodes. We could just state that they all are undef and save some memory. Differential Revision: https://reviews.llvm.org/D57567 Reviewed By: sanjoy llvm-svn: 353017
* [DA][NewPM] Handle transitive dependencies in the new-pm version of DAPhilip Pfaffe2019-02-031-0/+13
| | | | | | | | | | | | | | | | Summary: The analysis result of DA caches pointers to AA, SCEV, and LI, but it never checks for their invalidation. Fix that. Reviewers: chandlerc, dmgreen, bogner Reviewed By: dmgreen Subscribers: hiraditya, bollu, javed.absar, llvm-commits Differential Revision: https://reviews.llvm.org/D56381 llvm-svn: 352986
* [InstSimplify] Missed optimization in math expression: log10(pow(10.0,x)) == ↵Dmitry Venikov2019-02-031-1/+9
| | | | | | | | | | | | | | | | x, log2(pow(2.0,x)) == x Summary: This patch enables folding following instructions under -ffast-math flag: log10(pow(10.0,x)) -> x, log2(pow(2.0,x)) -> x Reviewers: hfinkel, spatel, efriedma, craig.topper, zvi, majnemer, lebedev.ri Reviewed By: spatel, lebedev.ri Subscribers: lebedev.ri, llvm-commits Differential Revision: https://reviews.llvm.org/D41940 llvm-svn: 352981
* Provide reason messages for unviable inliningYevgeny Rouban2019-02-011-9/+14
| | | | | | | | | | | | | InlineCost's isInlineViable() is changed to return InlineResult instead of bool. This provides messages for failure reasons and allows to get more specific messages for cases where callsites are not viable for inlining. Reviewed By: xbolva00, anemet Differential Revision: https://reviews.llvm.org/D57089 llvm-svn: 352849
* [MemorySSA] Extend removeMemoryAccess API to optimize MemoryPhis.Alina Sbirlea2019-01-311-1/+21
| | | | | | | | | | | | | | | | Summary: EarlyCSE needs to optimize MemoryPhis after an access is removed and has special handling for it. This should be handled by MemorySSA instead. The default remains that MemoryPhis are *not* optimized after an access is removed. Reviewers: george.burgess.iv Subscribers: sanjoy, jlebar, llvm-commits, Prazek Differential Revision: https://reviews.llvm.org/D57199 llvm-svn: 352787
* Test commit. NFCI.Yevgeny Rouban2019-01-311-1/+2
| | | | llvm-svn: 352738
* [SCEV] Prohibit SCEV transformations for huge SCEVsMax Kazantsev2019-01-311-3/+20
| | | | | | | | | | | | | | | | | | | | | | Currently SCEV attempts to limit transformations so that they do not work with big SCEVs (that may take almost infinite compile time). But for this, it uses heuristics such as recursion depth and number of operands, which do not give us a guarantee that we don't actually have big SCEVs. This situation is still possible, though it is not likely to happen. However, the bug PR33494 showed a bunch of simple corner case tests where we still produce huge SCEVs, even not reaching big recursion depth etc. This patch introduces a concept of 'huge' SCEVs. A SCEV is huge if its expression size (intoduced in D35989) exceeds some threshold value. We prohibit optimizing transformations if any of SCEVs we are dealing with is huge. This gives us a reliable check that we don't spend too much time working with them. As the next step, we can possibly get rid of old limiting mechanisms, such as recursion depth thresholds. Differential Revision: https://reviews.llvm.org/D35990 Reviewed By: reames llvm-svn: 352728
* Add a 'dynamic' parameter to the objectsize intrinsicErik Pilkington2019-01-301-16/+35
| | | | | | | | | | | | | | This is meant to be used with clang's __builtin_dynamic_object_size. When 'true' is passed to this parameter, the intrinsic has the potential to be folded into instructions that will be evaluated at run time. When 'false', the objectsize intrinsic behaviour is unchanged. rdar://32212419 Differential revision: https://reviews.llvm.org/D56761 llvm-svn: 352664
* [NFC] fix trivial typos in commentsHiroshi Inoue2019-01-304-7/+7
| | | | llvm-svn: 352602
* [NFC] Use ArrayRef instead of SmallVectorImpl where possibleMax Kazantsev2019-01-291-6/+6
| | | | llvm-svn: 352466
* [SCEV] Take correct loop in AddRec simplification. PR40420Max Kazantsev2019-01-291-1/+1
| | | | | | | | | | | | The code of AddRec simplification is using wrong loop when it creates a new AddRecExpr. It should be using AddRecLoop which we have saved and against which all gate checks are made, and not calling AddRec->getLoop() over and over again because AddRec may change and become an AddRecurrency from outer loop during the transform iterations. Considering this change trivial, commiting for postcommit review. llvm-svn: 352451
* [ThinLTO] Add option to dump per-module summary dot graphTeresa Johnson2019-01-281-0/+14
| | | | | | | | | | | | | | | | | | | | Summary: I found that there currently isn't a way to invoke exportToDot from the command line for a per-module summary index, and therefore no testing of that case. Add an internal option and use it to test dumping of per module summary indexes. In particular, I am looking at fixing the limitation that causes the aliasee GUID in the per-module summary to be 0, and want to be able to test that change. Reviewers: evgeny777 Subscribers: mehdi_amini, inglorion, eraman, steven_wu, dexonsmith, llvm-commits Differential Revision: https://reviews.llvm.org/D57206 llvm-svn: 352441
* [AliasSetTracker] Cleanup more comments. [NFCI]Alina Sbirlea2019-01-281-4/+6
| | | | llvm-svn: 352416
* [AliasSetTracker] Cleanup comments. [NFCI]Alina Sbirlea2019-01-281-5/+8
| | | | llvm-svn: 352406
* [AliasSetTracker] Update signature to aliasesPointer [NFCI].Alina Sbirlea2019-01-281-11/+13
| | | | llvm-svn: 352399
* [ValueTracking] Look through casts when determining non-nullnessJohannes Doerfert2019-01-261-0/+22
| | | | | | | | | | Bitcast and certain Ptr2Int/Int2Ptr instructions will not alter the value of their operand and can therefore be looked through when we determine non-nullness. Differential Revision: https://reviews.llvm.org/D54956 llvm-svn: 352293
* [Analysis] Fix isSafeToLoadUnconditionally handling of volatile.Eli Friedman2019-01-241-0/+8
| | | | | | | | | A volatile operation cannot be used to prove an address points to normal memory. (LangRef was recently updated to state it explicitly.) Differential Revision: https://reviews.llvm.org/D57040 llvm-svn: 352109
* Move saturated arithmetic intrinsics to other integer intrinsics. NFCI.Simon Pilgrim2019-01-231-4/+4
| | | | | | They were in the floating point group. llvm-svn: 351953
* [NFC] Add function to parse widenable conditional branchesMax Kazantsev2019-01-221-17/+14
| | | | llvm-svn: 351803
* [NFC] Add detector for guards expressed as branch by widenable conditionsMax Kazantsev2019-01-221-0/+27
| | | | | | | | | | | | | | | | | | | | | This patch adds a function to detect guards expressed in explicit control flow form as branch by `and` with widenable condition intrinsic call: %wc = call i1 @llvm.experimental.widenable.condition() %guard_cond = and i1, %some_cond, %wc br i1 %guard_cond, label %guarded, label %deopt deopt: <maybe some non-side-effecting instructions> deoptimize() This form can be used as alternative to implicit control flow guard representation expressed by `experimental_guard` intrinsic. Differential Revision: https://reviews.llvm.org/D56074 Reviewed By: reames llvm-svn: 351791
* [CVP] Use LVI to constant fold deopt operandsPhilip Reames2019-01-221-1/+3
| | | | | | | | Deopt operands are generally intended to record information about a site in code with minimal perturbation of the surrounding code. Idiomatically, they also tend to appear down rare paths. Putting these together, we have an obvious case for extending CVP w/deopt operand constant folding. Arguably, we should be doing this for all operands on all instructions, but that's definitely a much larger and risky change. Differential Revision: https://reviews.llvm.org/D55678 llvm-svn: 351774
* [SCEV][NFC] Introduces expression sizes estimationMax Kazantsev2019-01-211-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch introduces the field `ExpressionSize` in SCEV. This field is calculated only once on SCEV creation, and it represents the complexity of this SCEV from arithmetical point of view (not from the point of the number of actual different SCEV nodes that are used in the expression). Roughly saying, it is the number of operands and operations symbols when we print this SCEV. A formal definition is following: if SCEV `X` has operands `Op1`, `Op2`, ..., `OpN`, then Size(X) = 1 + Size(Op1) + Size(Op2) + ... + Size(OpN). Size of SCEVConstant and SCEVUnknown is one. Expression size may be used as a universal way to limit SCEV transformations for huge SCEVs. Currently, we have a bunch of options that represents various limits (such as recursion depth limit) that may not make any sense from the point of view of a LLVM users who is not familiar with SCEV internals, and all these different options pursue one goal. A more general rule that may potentially allow us to get rid of this redundancy in options is "do not make transformations with SCEVs of huge size". It can apply to all SCEV traversals and transformations that may need to visit a SCEV node more than once, hence they are prone to combinatorial explosions. This patch only introduces SCEV sizes calculation as NFC, its utilization will be introduced in follow-up patches. Differential Revision: https://reviews.llvm.org/D35989 Reviewed By: reames llvm-svn: 351725
* Update the file headers across all of the LLVM projects in the monorepoChandler Carruth2019-01-1998-392/+294
| | | | | | | | | | | | | | | | | to reflect the new license. We understand that people may be surprised that we're moving the header entirely to discuss the new license. We checked this carefully with the Foundation's lawyer and we believe this is the correct approach. Essentially, all code in the project is now made available by the LLVM project under our new license, so you will see that the license headers include that license only. Some of our contributors have contributed code under our old license, and accordingly, we have retained a copy of our old license notice in the top-level files in each project and repository. llvm-svn: 351636
* Revert "[ThinLTO] Add summary entries for index-based WPD"Teresa Johnson2019-01-171-111/+4
| | | | | | | | Mistaken commit of something still under review! This reverts commit r351453. llvm-svn: 351455
* [ThinLTO] Add summary entries for index-based WPDTeresa Johnson2019-01-171-4/+111
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: If LTOUnit splitting is disabled, the module summary analysis computes the summary information necessary to perform single implementation devirtualization during the thin link with the index and no IR. The information collected from the regular LTO IR in the current hybrid WPD algorithm is summarized, including: 1) For vtable definitions, record the function pointers and their offset within the vtable initializer (subsumes the information collected from IR by tryFindVirtualCallTargets). 2) A record for each type metadata summarizing the vtable definitions decorated with that metadata (subsumes the TypeIdentiferMap collected from IR). Also added are the necessary bitcode records, and the corresponding assembly support. The index-based WPD will be sent as a follow-on. Depends on D53890. Reviewers: pcc Subscribers: mehdi_amini, Prazek, inglorion, eraman, steven_wu, dexonsmith, arphaman, llvm-commits Differential Revision: https://reviews.llvm.org/D54815 llvm-svn: 351453
* Only promote args when function attributes are compatibleTom Stellard2019-01-161-0/+6
| | | | | | | | | | | | | | | | | | | | | | | | | Summary: Check to make sure that the caller and the callee have compatible function arguments before promoting arguments. This uses the same TargetTransformInfo queries that are used to determine if attributes are compatible for inlining. The goal here is to avoid breaking ABI when a called function's ABI depends on a target feature that is not enabled in the caller. This is a very conservative fix for PR37358. Ideally we would have a more sophisticated check for ABI compatiblity rather than checking if the attributes are compatible for inlining. Reviewers: echristo, chandlerc, eli.friedman, craig.topper Reviewed By: echristo, chandlerc Subscribers: nikic, xbolva00, rkruppe, alexcrichton, llvm-commits Differential Revision: https://reviews.llvm.org/D53554 llvm-svn: 351296
* Reapply "[DemandedBits] Use SetVector for Worklist"Nikita Popov2019-01-121-7/+6
| | | | | | | | | | | | | | | | DemandedBits currently uses a simple vector for the worklist, which means that instructions may be inserted multiple times into it. Especially in combination with the deep lattice, this may cause instructions too be recomputed very often. To avoid this, switch to a SetVector. Reapplying with a smaller number of inline elements in the SmallSetVector, to avoid running into the SmallDenseMap issue described in D56455. Differential Revision: https://reviews.llvm.org/D56362 llvm-svn: 350997
* [ConstantFolding] Fold undef for integer intrinsicsNikita Popov2019-01-111-63/+114
| | | | | | | | | | | | | | | | | | | This fixes https://bugs.llvm.org/show_bug.cgi?id=40110. This implements handling of undef operands for integer intrinsics in ConstantFolding, in particular for the bitcounting intrinsics (ctpop, cttz, ctlz), the with.overflow intrinsics, the saturating math intrinsics and the funnel shift intrinsics. The undef behavior follows what InstSimplify does for the general cas e of non-constant operands. For the bitcount intrinsics (where InstSimplify doesn't do undef handling -- there cannot be a combination of an undef + non-constant operand) I'm using a 0 result if the intrinsic is defined for zero and undef otherwise. Differential Revision: https://reviews.llvm.org/D55950 llvm-svn: 350971
* [LTO] Record whether LTOUnit splitting is enabled in indexTeresa Johnson2019-01-111-1/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: Records in the module summary index whether the bitcode was compiled with the option necessary to enable splitting the LTO unit (e.g. -fsanitize=cfi, -fwhole-program-vtables, or -fsplit-lto-unit). The information is passed down to the ModuleSummaryIndex builder via a new module flag "EnableSplitLTOUnit", which is propagated onto a flag on the summary index. This is then used during the LTO link to check whether all linked summaries were built with the same value of this flag. If not, an error is issued when we detect a situation requiring whole program visibility of the class hierarchy. This is the case when both of the following conditions are met: 1) We are performing LowerTypeTests or Whole Program Devirtualization. 2) There are type tests or type checked loads in the code. Note I have also changed the ThinLTOBitcodeWriter to also gate the module splitting on the value of this flag. Reviewers: pcc Subscribers: ormris, mehdi_amini, Prazek, inglorion, eraman, steven_wu, dexonsmith, arphaman, dang, llvm-commits Differential Revision: https://reviews.llvm.org/D53890 llvm-svn: 350948
* [MemorySSA] Disable checkClobberSanity for SkipSelfWalker.Alina Sbirlea2019-01-101-1/+2
| | | | | | | | | Sanity will fail for this, since we're exploring getting a clobber further than the sanity check expects. Ideally we need to teach the sanity check to differentiate between the two walkers based on the SkipSelf bool in the query. llvm-svn: 350895
* Refactor synthetic profile count computation. NFC.Easwaran Raman2019-01-091-19/+10
| | | | | | | | | | | | | | | | | Summary: Instead of using two separate callbacks to return the entry count and the relative block frequency, use a single callback to return callsite count. This would allow better supporting hybrid mode in the future as the count of callsite need not always be derived from entry count (as in sample PGO). Reviewers: davidxl Subscribers: mehdi_amini, steven_wu, dexonsmith, dang, llvm-commits Differential Revision: https://reviews.llvm.org/D56464 llvm-svn: 350755
* [Inliner] Assert that the computed inline threshold is non-negative.Easwaran Raman2019-01-091-0/+7
| | | | | | | | | | Reviewers: chandlerc Subscribers: haicheng, llvm-commits Differential Revision: https://reviews.llvm.org/D56409 llvm-svn: 350751
* refactor BlockFrequencyInfo::view to take a title parameterDavid Callahan2019-01-091-2/+2
| | | | | | | | | | | | | | Summary: All a non-default title for the debugging this debugging aide Reviewers: twoh, Kader, modocache Reviewed By: twoh Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D56499 llvm-svn: 350749
* [IPT] Drop cache less eagerly in GVN and LoopSafetyInfoMax Kazantsev2019-01-092-9/+16
| | | | | | | | | | | | | | | | | | | | Current strategy of dropping `InstructionPrecedenceTracking` cache is to invalidate the entire basic block whenever we change its contents. In fact, `InstructionPrecedenceTracking` has 2 internal strictures: `OrderedInstructions` that is needed to be invalidated whenever the contents changes, and the map with first special instructions in block. This second map does not need an update if we add/remove a non-special instuction because it cannot affect the contents of this map. This patch changes API of `InstructionPrecedenceTracking` so that it now accounts for reasons under which we invalidate blocks. This should lead to much less recalculations of the map and should save us some compile time because in practice we don't typically add/remove special instructions. Differential Revision: https://reviews.llvm.org/D54462 Reviewed By: efriedma llvm-svn: 350694
OpenPOWER on IntegriCloud