summaryrefslogtreecommitdiffstats
path: root/llvm/lib/Transforms
Commit message (Collapse)AuthorAgeFilesLines
* [GVNHoist] Re-enable GVNHoist by defaultAlexandros Lamprineas2018-08-291-2/+2
| | | | | | | | | Rebase rL338240 since the excessive memory usage observed when using GVNHoist with UBSan has been fixed by rL340818. Differential Revision: https://reviews.llvm.org/D49858 llvm-svn: 340922
* [NFC] Unify guards detectionMax Kazantsev2018-08-296-15/+16
| | | | | | | | | | | We have multiple places in code where we try to identify whether or not some instruction is a guard. This patch factors out this logic into a separate utility function which works uniformly in all places. Differential Revision: https://reviews.llvm.org/D51152 Reviewed By: fedor.sergeev llvm-svn: 340921
* [NFC] Factor out guard utility methods into a separate fileMax Kazantsev2018-08-293-48/+67
| | | | | | | | | | This patch creates file GuardUtils which will contain logic for work with guards that can be shared across different passes. Differential Revision: https://reviews.llvm.org/D51151 Reviewed By: fedor.sergeev llvm-svn: 340914
* LoopSink: Don't sink into blocks without an insertion point (PR38462)Hans Wennborg2018-08-291-0/+8
| | | | | | | | | In the PR, LoopSink was trying to sink into a catchswitch block, which doesn't have a valid insertion point. Differential Revision: https://reviews.llvm.org/D51307 llvm-svn: 340900
* [QTOOL-37352] Consider isLegalAddressingImm in Constant HoistingZhaoshi Zheng2018-08-281-1/+21
| | | | | | | | | | | | | | In Thumb1, legal imm range is [0, 255] for ADD/SUB instructions. However, the legal imm range for LD/ST in (R+Imm) addressing mode is [0, 127]. Imms in [128, 255] are materialized by mov R, #imm, and LD/STs use them in (R+R) addressing mode. This patch checks if a constant is used as offset in (R+Imm), if so, it checks isLegalAddressingMode passing the constant value as BaseOffset. Differential Revision: https://reviews.llvm.org/D50931 llvm-svn: 340882
* [SimpleLoopUnswitch] Form dedicated exits after trivial unswitches.Alina Sbirlea2018-08-281-5/+8
| | | | | | | | | | | | | | Summary: Form dedicated exits after trivial unswitches. Fixes PR38737, PR38283. Reviewers: chandlerc, fedor.sergeev Subscribers: sanjoy, jlebar, uabelho, llvm-commits Differential Revision: https://reviews.llvm.org/D51375 llvm-svn: 340871
* Revert "[libFuzzer] Port to Windows"Matt Morehouse2018-08-281-23/+6
| | | | | | This reverts commit r340860 due to failing tests. llvm-svn: 340867
* [libFuzzer] Port to WindowsMatt Morehouse2018-08-281-6/+23
| | | | | | | | | | | | | | | | | | | | Summary: Port libFuzzer to windows-msvc. This patch allows libFuzzer targets to be built and run on Windows, using -fsanitize=fuzzer and/or fsanitize=fuzzer-no-link. It allows these forms of coverage instrumentation to work on Windows as well. It does not fix all issues, such as those with -fsanitize-coverage=stack-depth, which is not usable on Windows as of this patch. It also does not fix any libFuzzer integration tests. Nearly all of them fail to compile, fixing them will come in a later patch, so libFuzzer tests are disabled on Windows until them. Patch By: metzman Reviewers: morehouse, rnk Reviewed By: morehouse, rnk Subscribers: morehouse, kcc, eraman Differential Revision: https://reviews.llvm.org/D51022 llvm-svn: 340860
* AMDGPU: Remove nan tests in class if src is nnanMatt Arsenault2018-08-281-0/+7
| | | | llvm-svn: 340850
* [Inliner] Attribute callsites with inline remarksDavid Bolvansky2018-08-281-10/+51
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: Sometimes reading an output *.ll file it is not easy to understand why some callsites are not inlined. We can read output of inline remarks (option --pass-remarks-missed=inline) and try correlating its messages with the callsites. An easier way proposed by this patch is to add to every callsite processed by Inliner an attribute with the latest message that describes the cause of not inlining this callsite. The attribute is called //inline-remark//. By default this feature is off. It can be switched on by the option //-inline-remark-attribute//. For example in the provided test the result method //@test1// has two callsites //@bar// and inline remarks report different inlining missed reasons: remark: <unknown>:0:0: bar not inlined into test1 because too costly to inline (cost=-5, threshold=-6) remark: <unknown>:0:0: bar not inlined into test1 because it should never be inlined (cost=never): recursive It is not clear which remark correspond to which callsite. With the inline remark attribute enabled we get the reasons attached to their callsites: define void @test1() { call void @bar(i1 true) #0 call void @bar(i1 false) #2 ret void } attributes #0 = { "inline-remark"="(cost=-5, threshold=-6)" } .. attributes #2 = { "inline-remark"="(cost=never): recursive" } Patch by: yrouban (Yevgeny Rouban) Reviewers: xbolva00, tejohnson, apilipenko Reviewed By: xbolva00, tejohnson Subscribers: eraman, llvm-commits Differential Revision: https://reviews.llvm.org/D50435 llvm-svn: 340834
* [CloneFunction] Constant fold terminators before checking single predecessorMikael Holmen2018-08-281-7/+16
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: This fixes PR31105. There is code trying to delete dead code that does so by e.g. checking if the single predecessor of a block is the block itself. That check fails on a block like this bb: br i1 undef, label %bb, label %bb since that has two (identical) predecessors. However, after the check for dead blocks there is a call to ConstantFoldTerminator on the basic block, and that call simplifies the block to bb: br label %bb Therefore we now do the call to ConstantFoldTerminator before the check if the block is dead, so it can realize that it really is. The original behavior lead to the block not being removed, but it was simplified as above, and then we did a call to Dest->replaceAllUsesWith(&*I); with old and new being equal, and an assertion triggered. Reviewers: chandlerc, fhahn Reviewed By: fhahn Subscribers: eraman, llvm-commits Differential Revision: https://reviews.llvm.org/D51280 llvm-svn: 340820
* [GVNHoist] Prune out useless CHI insertionsAlexandros Lamprineas2018-08-281-2/+5
| | | | | | | | | | Fix for the out-of-memory error when compiling SemaChecking.cpp with GVNHoist and ubsan enabled. I've used a cache for inserted CHIs to avoid excessive memory usage. Differential Revision: https://reviews.llvm.org/D50323 llvm-svn: 340818
* [NFC] A loop can never contain Ret instructionMax Kazantsev2018-08-281-1/+1
| | | | llvm-svn: 340808
* [InstCombine] Extend (add (sext x), cst) --> (sext (add x, cst')) and (add ↵Craig Topper2018-08-281-2/+4
| | | | | | | | (zext x), cst) --> (zext (add x, cst')) to work for vectors Differential Revision: https://reviews.llvm.org/D51236 llvm-svn: 340796
* [InstCombine] fix formatting; NFCSanjay Patel2018-08-271-1/+2
| | | | llvm-svn: 340790
* [InstCombine] allow shuffle+binop canonicalization with widening shufflesSanjay Patel2018-08-271-4/+14
| | | | | | | | This lines up with the behavior of an existing transform where if both operands of the binop are shuffled, we allow moving the binop before the shuffle regardless of whether the shuffle changes the size of the vector. llvm-svn: 340787
* [PATCH] [InstCombine] Fix issue in the simplification of pow() with nested ↵Evandro Menezes2018-08-271-6/+22
| | | | | | | | | | | exp{,2}() Fix the issue of duplicating the call to `exp{,2}()` when it's nested in `pow()`, as exposed by rL340462. Differential revision: https://reviews.llvm.org/D51194 llvm-svn: 340784
* s/std::set/DenseSet/; NFCGeorge Burgess IV2018-08-271-1/+1
| | | | | | | We only use this set for `insert` and `count`, so a hashing container seems better here. llvm-svn: 340783
* fix comment typoNico Weber2018-08-271-1/+1
| | | | llvm-svn: 340744
* [NFC] Split logic of ImplicitControlFlowTracking to allow generalizationMax Kazantsev2018-08-273-94/+100
| | | | | | | | | | | | | | | | | | | | | | | | | | We have a class `ImplicitControlFlowTracking` which allows us to keep track of instructions that can abnormally exit and answer queries like "whether or not there is side-exiting instruction above this instruction in its block". We may want to have the similar tracking for other types of "special" instructions, for example instructions that write memory. This patch separates ImplicitControlFlowTracking into two classes, isolating all general logic not related to implicit control flow into its parent class. We can later make another child of this class to keep track of instructions that write memory. The motivation for that is that we want to make these checks efficiently in the patch https://reviews.llvm.org/D50891. NOTE: The naming of the parent class is not super cool, but the other options we have are hardly better. Please feel free to rename it as NFC if you think you've found a more informative name for it. Differential Revision: https://reviews.llvm.org/D50954 Reviewed By: fedor.sergeev llvm-svn: 340728
* [IR] Replace `isa<TerminatorInst>` with `isTerminator()`.Chandler Carruth2018-08-2620-27/+29
| | | | | | | | | | | | This is a bit awkward in a handful of places where we didn't even have an instruction and now we have to see if we can build one. But on the whole, this seems like a win and at worst a reasonable cost for removing `TerminatorInst`. All of this is part of the removal of `TerminatorInst` from the `Instruction` type hierarchy. llvm-svn: 340701
* [IR] Sink `isExceptional` predicate to `Instruction`, rename it toChandler Carruth2018-08-266-6/+6
| | | | | | | | | | | `isExceptionalTermiantor` and implement it for opcodes as well following the common pattern in `Instruction`. Part of removing `TerminatorInst` from the `Instruction` type hierarchy to make it easier to share logic and interfaces between instructions that are both terminators and not terminators. llvm-svn: 340699
* [IR] Begin removal of TerminatorInst by removing successor manipulation.Chandler Carruth2018-08-268-12/+11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The core get and set routines move to the `Instruction` class. These routines are only valid to call on instructions which are terminators. The iterator and *generic* range based access move to `CFG.h` where all the other generic successor and predecessor access lives. While moving the iterator here, simplify it using the iterator utilities LLVM provides and updates coding style as much as reasonable. The APIs remain pointer-heavy when they could better use references, and retain the odd behavior of `operator*` and `operator->` that is common in LLVM iterators. Adjusting this API, if desired, should be a follow-up step. Non-generic range iteration is added for the two instructions where there is an especially easy mechanism and where there was code attempting to use the range accessor from a specific subclass: `indirectbr` and `br`. In both cases, the successors are contiguous operands and can be easily iterated via the operand list. This is the first major patch in removing the `TerminatorInst` type from the IR's instruction type hierarchy. This change was discussed in an RFC here and was pretty clearly positive: http://lists.llvm.org/pipermail/llvm-dev/2018-May/123407.html There will be a series of much more mechanical changes following this one to complete this move. Differential Revision: https://reviews.llvm.org/D47467 llvm-svn: 340698
* [PGO] add target md5sum in warning message for icallXinliang David Li2018-08-241-1/+2
| | | | | | Differential revision: http://reviews.llvm.org/D51193 llvm-svn: 340657
* [AST] Simplify code minorly using pattern match [NFC]Philip Reames2018-08-241-8/+4
| | | | llvm-svn: 340638
* Revert [Inliner] Attribute callsites with inline remarksDavid Bolvansky2018-08-241-51/+8
| | | | llvm-svn: 340619
* [Inliner] Attribute callsites with inline remarksDavid Bolvansky2018-08-241-8/+51
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: Sometimes reading an output *.ll file it is not easy to understand why some callsites are not inlined. We can read output of inline remarks (option --pass-remarks-missed=inline) and try correlating its messages with the callsites. An easier way proposed by this patch is to add to every callsite processed by Inliner an attribute with the latest message that describes the cause of not inlining this callsite. The attribute is called //inline-remark//. By default this feature is off. It can be switched on by the option //-inline-remark-attribute//. For example in the provided test the result method //@test1// has two callsites //@bar// and inline remarks report different inlining missed reasons: remark: <unknown>:0:0: bar not inlined into test1 because too costly to inline (cost=-5, threshold=-6) remark: <unknown>:0:0: bar not inlined into test1 because it should never be inlined (cost=never): recursive It is not clear which remark correspond to which callsite. With the inline remark attribute enabled we get the reasons attached to their callsites: define void @test1() { call void @bar(i1 true) #0 call void @bar(i1 false) #2 ret void } attributes #0 = { "inline-remark"="(cost=-5, threshold=-6)" } .. attributes #2 = { "inline-remark"="(cost=never): recursive" } Patch by: yrouban (Yevgeny Rouban) Reviewers: xbolva00, tejohnson, apilipenko Reviewed By: xbolva00, tejohnson Subscribers: eraman, llvm-commits Differential Revision: https://reviews.llvm.org/D50435 llvm-svn: 340618
* [LICM] Hoist an invariant_start out of loops if there are no stores executed ↵Philip Reames2018-08-241-1/+3
| | | | | | | | | | before it Once the invariant_start is reached, we know that no instruction *after* it can modify the memory. So, if we can prove the location isn't read *between entry into the loop and the execution of the invariant_start*, we can execute the invariant_start before entering the loop. Differential Revision: https://reviews.llvm.org/D51181 llvm-svn: 340617
* [Local] Make DoesKMove required for combineMetadata.Florian Hahn2018-08-248-11/+12
| | | | | | | | | | | | | | | This patch makes the DoesKMove argument non-optional, to force people to think about it. Most cases where it is false are either code hoisting or code sinking, where we pick one instruction from a set of equal instructions among different code paths. Reviewers: dberlin, nlopes, efriedma, davide Reviewed By: efriedma Differential Revision: https://reviews.llvm.org/D47475 llvm-svn: 340606
* [LoopVectorize][NFCI] Use find instead of countDavid Bolvansky2018-08-231-42/+58
| | | | | | | | | | | | | | | | | Summary: Avoid "count" if possible -> use "find" to check for the existence of keys. Passed llvm test suite. Reviewers: fhahn, dcaballe, mkuper, rengolin Reviewed By: fhahn Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D51054 llvm-svn: 340563
* [InstCombine] Fold Select with binary op - FP opcodesDavid Bolvansky2018-08-231-6/+19
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: Follow up for https://reviews.llvm.org/rL339520 and https://reviews.llvm.org/rL338300 Alive: ``` %A = fcmp oeq float %x, 0.0 %B = fadd nsz float %x, %z %C = select i1 %A, float %B, float %y => %C = select i1 %A, float %z, float %y ---------- %A = fcmp oeq float %x, 0.0 %B = fadd nsz float %x, %z %C = select %A, float %B, float %y => %C = select %A, float %z, float %y Done: 1 Optimization is correct %A = fcmp une float %x, -0.0 %B = fadd nsz float %x, %z %C = select i1 %A, float %y, float %B => %C = select i1 %A, float %y, float %z ---------- %A = fcmp une float %x, -0.0 %B = fadd nsz float %x, %z %C = select %A, float %y, float %B => %C = select %A, float %y, float %z Done: 1 Optimization is correct ``` Reviewers: spatel, lebedev.ri Reviewed By: spatel Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D50714 llvm-svn: 340538
* [FunctionAttrs] Infer WriteOnly Function AttributeBrian Homerding2018-08-231-10/+38
| | | | | | | | | | | | These changes expand the FunctionAttr logic in order to mark functions as WriteOnly when appropriate. This is done through an additional bool variable and extended logic. Reviewers: hfinkel, jdoerfert Differential Revision: https://reviews.llvm.org/D48387 llvm-svn: 340537
* [GVN] Invalidate cached info for phis when setting dead predecessors to undefJohn Brawn2018-08-231-0/+2
| | | | | | | | | | When GVN sets the incoming value for a phi to undef because the incoming block is unreachable it needs to also invalidate the cached info for that phi in MemoryDependenceAnalysis, otherwise later queries will return stale information. Differential Revision: https://reviews.llvm.org/D51099 llvm-svn: 340529
* [SCCP] Remove unused variable added in r340525.Florian Hahn2018-08-231-1/+1
| | | | llvm-svn: 340526
* Recommit r333268: [IPSCCP] Use PredicateInfo to propagate facts from cmp ↵Florian Hahn2018-08-232-10/+137
| | | | | | | | | | | | | | | | | | | | | | instructions. This version of the patch fixes cleaning up ssa_copy intrinsics, so it does not crash for instructions in blocks that have been marked unreachable. This patch updates IPSCCP to use PredicateInfo to propagate facts to true branches predicated by EQ and to false branches predicated by NE. As a follow up, we should be able to extend it to also propagate additional facts about nonnull. Reviewers: davide, mssimpso, dberlin, efriedma Reviewed By: davide, dberlin Differential Revision: https://reviews.llvm.org/D45330 llvm-svn: 340525
* Allow creating llvm::Function in non-zero address spacesAlexander Richardson2018-08-234-13/+14
| | | | | | | | | | | | | | | | | | | | Most users won't have to worry about this as all of the 'getOrInsertFunction' functions on Module will default to the program address space. An overload has been added to Function::Create to abstract away the details for most callers. This is based on https://reviews.llvm.org/D37054 but without the changes to make passing a Module to Function::Create() mandatory. I have also added some more tests and fixed the LLParser to accept call instructions for types in the program address space. Reviewed By: bjope Differential Revision: https://reviews.llvm.org/D47541 llvm-svn: 340519
* [LibCalls] Added returned attribute to libcallsDavid Bolvansky2018-08-231-3/+16
| | | | | | | | | | | | Reviewers: efriedma Reviewed By: efriedma Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D51092 llvm-svn: 340512
* [NFC] Refactor simplification of pow()Evandro Menezes2018-08-221-1/+1
| | | | llvm-svn: 340476
* Update MemorySSA in LoopSimplifyCFG.Alina Sbirlea2018-08-221-4/+23
| | | | | | | | | | | | | | Summary: Add MemorySSA as a dependency to LoopSimplifyCFG and preserve it. Disabled by default until all passes preserve MemorySSA. Reviewers: bogner, chandlerc Subscribers: sanjoy, jlebar, Prazek, george.burgess.iv, llvm-commits Differential Revision: https://reviews.llvm.org/D50911 llvm-svn: 340445
* Update MemorySSA in LoopInstSimplify.Alina Sbirlea2018-08-221-6/+38
| | | | | | | | | | | | | | Summary: Add MemorySSA as a depency to LoopInstInstSimplify and preserve it. Disabled by default until all passes preserve MemorySSA. Reviewers: chandlerc Subscribers: sanjoy, jlebar, Prazek, george.burgess.iv, llvm-commits Differential Revision: https://reviews.llvm.org/D50906 llvm-svn: 340444
* [GuardWidening] Ignore guards with trivial conditionsMax Kazantsev2018-08-221-0/+6
| | | | | | | | | | | | Guard widening should not spend efforts on dealing with guards with trivial true/false conditions. Such guards can easily be eliminated by any further cleanup pass like instcombine. However we should not unconditionally delete them because it may be profitable to widen other conditions into such guards. Differential Revision: https://reviews.llvm.org/D50247 Reviewed By: fedor.sergeev llvm-svn: 340381
* Update MemorySSA in BasicBlockUtils.Alina Sbirlea2018-08-218-26/+48
| | | | | | | | | | | Summary: Extend BasicBlocksUtils to update MemorySSA. Subscribers: sanjoy, arsenm, nhaehnle, jlebar, Prazek, llvm-commits Differential Revision: https://reviews.llvm.org/D45300 llvm-svn: 340365
* [LICM] Refactor some AliasSetTracker code to get rid of new/deletes. NFCMarcello Maggioni2018-08-211-43/+33
| | | | | | Differential Revision: https://reviews.llvm.org/D51024 llvm-svn: 340333
* [CodeExtractor] Use 'normal destination' BB as insert point to store invoke ↵Florian Hahn2018-08-211-1/+9
| | | | | | | | | | | | | | | | | | | results. Currently CodeExtractor tries to use the next node after an invoke to place the store for the result of the invoke, if it is an out parameter of the region. This fails, as the invoke terminates the current BB. In that case, we can place the store in the 'normal destination' BB, as the result will only be available in that case. Reviewers: davidxl, davide, efriedma Reviewed By: davidxl Differential Revision: https://reviews.llvm.org/D51037 llvm-svn: 340331
* [InstCombine] Pull simple checks above a more complicated one. NFCICraig Topper2018-08-211-4/+2
| | | | | | I'm assuming its easier to make sure the RHS of an XOR is all ones than it is to check for the many select patterns we have. So lets check that first. Same with the one use check. llvm-svn: 340321
* [GVN] Assign new value number to calls reading memory, if there is no MemDep ↵Florian Hahn2018-08-211-13/+9
| | | | | | | | | | | | | | | | | | | | | | info. Currently we assign the same value number to two calls reading the same memory location if we do not have MemoryDependence info. Without MemDep Info we cannot guarantee that there is no store between the two calls, so we have to assign a new number to the second call. It also adds a new option EnableMemDep to enable/disable running MemoryDependenceAnalysis and also renamed NoLoads to NoMemDepAnalysis to be more explicit what it does. As it also impacts calls that read memory, NoLoads is a bit confusing. Reviewers: efriedma, sebpop, john.brawn, wmi Reviewed By: efriedma Differential Revision: https://reviews.llvm.org/D50893 llvm-svn: 340319
* [AST] Remove notion of volatile from alias sets [NFCI]Philip Reames2018-08-211-3/+1
| | | | | | | | | | Volatility is not an aliasing property. We used to model volatile as if it had extremely conservative aliasing implications, but that hasn't been true for several years now. So, it doesn't make sense to be in AliasSet. It also turns out the code is entirely a noop. Outside of the AST code to update it, there was only one user: load store promotion in LICM. L/S promotion doesn't need the check since it walks all the users of the address anyway. It already checks each load or store via !isUnordered which causes us to bail for volatile accesses. (Look at the lines immediately following the two remove asserts.) There is the possibility of some small compile time impact here, but the only case which will get noticeably slower is a loop with a large number of loads and stores to the same address where only the last one we inspect is volatile. This is sufficiently rare it's not worth optimizing for.. llvm-svn: 340312
* [BypassSlowDivision] Teach bypass slow division not to interfere with div by ↵Craig Topper2018-08-211-0/+9
| | | | | | | | | | | | | | constant where constants have been constant hoisted, but not moved from their basic block DAGCombiner doesn't pay attention to whether constants are opaque before doing the div by constant optimization. So BypassSlowDivision shouldn't introduce control flow that would make DAGCombiner unable to see an opaque constant. This can occur when a div and rem of the same constant are used in the same basic block. it will be hoisted, but not leave the block. Longer term we probably need to look into the X86 immediate cost model used by constant hoisting and maybe not mark div/rem immediates for hoisting at all. This fixes the case from PR38649. Differential Revision: https://reviews.llvm.org/D51000 llvm-svn: 340303
* [LV] Vectorize loops where non-phi instructions used outside loopAnna Thomas2018-08-212-7/+36
| | | | | | | | | | | | | | | | | | | Summary: Follow up change to rL339703, where we now vectorize loops with non-phi instructions used outside the loop. Note that the cyclic dependency identification occurs when identifying reduction/induction vars. We also need to identify that we do not allow users where the PSCEV information within and outside the loop are different. This was the fix added in rL307837 for PR33706. Reviewers: Ayal, mkuper, fhahn Subscribers: javed.absar, llvm-commits Differential Revision: https://reviews.llvm.org/D50778 llvm-svn: 340278
* [LICM] Hoist guards with invariant conditionsMax Kazantsev2018-08-211-0/+17
| | | | | | | | | | This patch teaches LICM to hoist guards from the loop if they are guaranteed to execute and if there are no side effects that could prevent that. Differential Revision: https://reviews.llvm.org/D50501 Reviewed By: reames llvm-svn: 340256
OpenPOWER on IntegriCloud