summaryrefslogtreecommitdiffstats
path: root/llvm/lib/Transforms/InstCombine/InstructionCombining.cpp
Commit message (Collapse)AuthorAgeFilesLines
* [KnownBits] Add methods for determining if KnownBits is a constant valueCraig Topper2017-05-031-4/+4
| | | | | | | | This patch adds isConstant and getConstant for determining if KnownBits represents a constant value and to retrieve the value. Use them to simplify code. Differential Revision: https://reviews.llvm.org/D32785 llvm-svn: 302091
* Rename WeakVH to WeakTrackingVH; NFCSanjoy Das2017-05-011-4/+4
| | | | | | This relands r301424. llvm-svn: 301812
* InstCombine: Use the new SimplifyQuery versions of Simplify*. Use ↵Daniel Berlin2017-04-261-26/+24
| | | | | | AssumptionCache, DominatorTree, TargetLibraryInfo everywhere. llvm-svn: 301464
* [ValueTracking] Introduce a KnownBits struct to wrap the two APInts for ↵Craig Topper2017-04-261-14/+13
| | | | | | | | | | | | | | | | computeKnownBits This patch introduces a new KnownBits struct that wraps the two APInt used by computeKnownBits. This allows us to treat them as more of a unit. Initially I've just altered the signatures of computeKnownBits and InstCombine's simplifyDemandedBits to pass a KnownBits reference instead of two separate APInt references. I'll do similar to the SelectionDAG version of computeKnownBits/simplifyDemandedBits as a separate patch. I've added a constructor that allows initializing both APInts to the same bit width with a starting value of 0. This reduces the repeated pattern of initializing both APInts. Once place default constructed the APInts so I added a default constructor for those cases. Going forward I would like to add more methods that will work on the pairs. For example trunc, zext, and sext occur on both APInts together in several places. We should probably add a clear method that can be used to clear both pieces. Maybe a method to check for conflicting information. A method to return (Zero|One) so we don't write it out everywhere. Maybe a method for (Zero|One).isAllOnesValue() to determine if all bits are known. I'm sure there are many other methods we can come up with. Differential Revision: https://reviews.llvm.org/D32376 llvm-svn: 301432
* Reverts commit r301424, r301425 and r301426Sanjoy Das2017-04-261-4/+4
| | | | | | | | | | | | Commits were: "Use WeakVH instead of WeakTrackingVH in AliasSetTracker's UnkownInsts" "Add a new WeakVH value handle; NFC" "Rename WeakVH to WeakTrackingVH; NFC" The changes assumed pointers are 8 byte aligned on all architectures. llvm-svn: 301429
* Rename WeakVH to WeakTrackingVH; NFCSanjoy Das2017-04-261-4/+4
| | | | | | | | | | | | | | | | Summary: I plan to use WeakVH to mean "nulls itself out on deletion, but does not track RAUW" in a subsequent commit. Reviewers: dblaikie, davide Reviewed By: davide Subscribers: arsenm, mehdi_amini, mcrosier, mzolotukhin, jfb, llvm-commits, nhaehnle Differential Revision: https://reviews.llvm.org/D32266 llvm-svn: 301424
* [InstCombine] Remove redundant code from SimplifyUsingDistributiveLawsCraig Topper2017-04-251-16/+0
| | | | | | | | | | The code I've removed here exists in ExpandBinOp in InstSimplify which we call into before SimplifyUsingDistributiveLaws. The code in InstSimplify looks to have been copied from here. I verified this code doesn't fire on any lit tests. Not that that proves its definitely dead. Differential Revision: https://reviews.llvm.org/D32472 llvm-svn: 301341
* [APInt] Cast calls to add/sub/mul overflow methods to void if only their ↵Craig Topper2017-04-191-2/+2
| | | | | | | | | | overflow bool out param is used. This is preparation for a clang change to improve the [[nodiscard]] warning to not be ignored on methods that return a class marked [[nodiscard]] that are defined in the class itself. See D32207. We should consider adding wrapper methods to APInt that return the overflow flag directly and discard the APInt result. This would eliminate the void casts and the need to create a bool before the call to pass to the out param. llvm-svn: 300758
* [InstCombine] Support folding a subtract with a constant LHS into a phi nodeCraig Topper2017-04-141-16/+27
| | | | | | | | | | | | We currently only support folding a subtract into a select but not a PHI. This fixes that. I had to fix an assumption in FoldOpIntoPhi that assumed the PHI node was always in operand 0. Now we pass it in like we do for FoldOpIntoSelect. But we still require some dancing to find the Constant when we create the BinOp or ConstantExpr. This is based code is similar to what we do for selects. Since I touched all call sites, this also renames FoldOpIntoPhi to foldOpIntoPhi to match coding standards. Differential Revision: https://reviews.llvm.org/D31686 llvm-svn: 300363
* [InstCombine] Refactor SimplifyUsingDistributiveLaws to more explicitly skip ↵Craig Topper2017-04-141-30/+33
| | | | | | | | | | | | | | code when LHS/RHS aren't BinaryOperators Currently this code always makes 2 or 3 calls to tryFactorization regardless of whether the LHS/RHS are BinaryOperators. We make 3 calls when both operands are BinaryOperators with the same opcode. Or surprisingly, when neither are BinaryOperators. This is because getBinOpsForFactorization returns Instruction::BinaryOpsEnd when the operand is not a BinaryOperator. If both LHS and RHS are not BinaryOperators then they both have an Opcode of Instruction::BinaryOpsEnd. When this happens we rely on tryFactorization to early out due to A/B/C/D being null. Similar behavior occurs for the other calls, we rely on getBinOpsForFactorization having made A/B or C/D null to get tryFactorization to early out. We also rely on these null checks to check the result of getIdentityValue and early out for it. This patches refactors this to pull these checks up to SimplifyUsingDistributiveLaws so we don't rely on BinaryOpsEnd as a sentinel or this A/B/C/D null behavior. I think this makes this code easier to reason about. Should also give a tiny performance improvement for cases where the LHS or RHS isn't a BinaryOperator. Differential Revision: https://reviews.llvm.org/D31913 llvm-svn: 300353
* [IR] Redesign the case iterator in SwitchInst to actually be an iteratorChandler Carruth2017-04-121-17/+7
| | | | | | | | | | | | | | | | and to expose a handle to represent the actual case rather than having the iterator return a reference to itself. All of this allows the iterator to be used with common STL facilities, standard algorithms, etc. Doing this exposed some missing facilities in the iterator facade that I've fixed and required some work to the actual iterator to fully support the necessary API. Differential Revision: https://reviews.llvm.org/D31548 llvm-svn: 300032
* [InstCombine] Use ConstantExpr::getBinOpIdentity to implement getIdentityValue.Craig Topper2017-04-111-7/+2
| | | | | | This removes a TODO in getIdentityValue and may allow some transforms to occur earlier. But I was unable to find any transforms we didn't already handle. llvm-svn: 299966
* [InstCombine] Refinement of r299915. Only consider a ConstantVector for Neg ↵Craig Topper2017-04-111-3/+14
| | | | | | if all the elements are Undef or ConstantInt. llvm-svn: 299917
* [InstCombine] Support weird size element types in dyn_castNegVal.Craig Topper2017-04-111-0/+4
| | | | llvm-svn: 299915
* [InstCombine] Make sure we preserve fast math flags when folding fp ↵Craig Topper2017-04-101-2/+6
| | | | | | | | | | | | | | | | instructions into phi nodes Summary: I noticed in the select folding code that we copied fast math flags, but did not do the same for the similar handling in phi nodes. This patch fixes that to do the same thing as select Reviewers: spatel, davide, majnemer, hfinkel Reviewed By: davide Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D31690 llvm-svn: 299838
* [InstCombine] Make foldOpWithConstantIntoOperand take a BinaryOperator ↵Craig Topper2017-04-031-1/+1
| | | | | | | | instead of a generic Instruction. It blindly assumes there are two operands so make it explicit. llvm-svn: 299351
* [InstCombine] When adding an Instruction and its Users to the worklist at ↵Craig Topper2017-03-311-2/+2
| | | | | | | | the same time, make sure we put the Users in first. Then put in the instruction. This way we ensure we immediately revisit the instruction and do any additional optimizations before visiting the users. Otherwise we might visit the users, then the instruction, then users again, then instruction again. llvm-svn: 299267
* [InstCombine] Correct the check for vector GEPsMatthew Simpson2017-03-291-5/+5
| | | | | | | | | | | | | | Some of the GEP combines (e.g., descaling) can't handle vector GEPs. We have an existing check that attempts to bail out if given a vector GEP. However, the check only tests the GEP's pointer operand. A GEP results in a vector of pointers if at least one of its operands is vector-typed (e.g., its pointer operand could be a scalar, but its index could be a vector). We should just check the type of the GEP itself. This should fix PR32414. Reference: https://bugs.llvm.org/show_bug.cgi?id=32414 Differential Revision: https://reviews.llvm.org/D31470 llvm-svn: 299017
* [InstCombine] For select rule, use positive check of constant int for select ↵Anna Thomas2017-03-281-1/+1
| | | | | | operand. NFCI llvm-svn: 298906
* [InstCombine] Avoid incorrect folding of select into phi nodes when incoming ↵Anna Thomas2017-03-271-1/+5
| | | | | | | | | | | | | | | | | | | | | | element is a vector type Summary: We are incorrectly folding selects into phi nodes when the incoming value of a phi node is a constant vector. This optimization is done in `FoldOpIntoPhi` when the select condition is a phi node with constant incoming values. Without the fix, we are miscompiling (i.e. incorrectly folding the select into the phi node) when the vector contains non-zero elements. This patch fixes the miscompile and we will correctly fold based on the select vector operand (see added test cases). Reviewers: majnemer, sanjoy, spatel Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D31189 llvm-svn: 298845
* [InstCombine] Use range-based for loop. NFCCraig Topper2017-03-241-5/+4
| | | | llvm-svn: 298680
* [InstCombine] Fix 80 column violation I accidentally introduced. NFCCraig Topper2017-03-241-1/+2
| | | | llvm-svn: 298679
* [InstCombine] Print a debug message when we constant fold an operand during ↵Craig Topper2017-03-201-0/+2
| | | | | | | | | | | | worklist creation InstCombine tries to constant fold instruction operands during worklist building, but we don't print that we're doing this. We also set a change flag here that causes us to rebuild and rerun the worklist one more time even if processing the worklist itself created no additional changes. So in the log I saw two inst combine runs that visited all instructions without printing that anything was changed. I may be submitting another patch to remove the change flag unless I can find some reason why we should be doing that. Differential Revision: https://reviews.llvm.org/D31091 llvm-svn: 298264
* [InstCombine] use dyn_cast instead of isa+cast; NFCISanjay Patel2017-03-061-15/+12
| | | | llvm-svn: 297092
* [InstCombine] Make max size array combine a tunable.Davide Italiano2017-02-071-0/+5
| | | | | | | Requested by Sanjoy/Hal a while ago, and forgotten by me (r283612). llvm-svn: 294323
* [InstCombine] simplify dyn_cast + isa; NFCISanjay Patel2017-02-061-6/+4
| | | | llvm-svn: 294198
* [InstCombine] treat i1 as a special type in shouldChangeType()Sanjay Patel2017-02-031-4/+8
| | | | | | | | | | | | | | | | | | | | This patch is based on the llvm-dev discussion here: http://lists.llvm.org/pipermail/llvm-dev/2017-January/109631.html Folding to i1 should always be desirable because that's better for value tracking and we have special folds for i1 types. I checked for other users of shouldChangeType() where this might have an effect, but we already handle the i1 case differently than other types in all of those cases. Side note: the default datalayout includes i1, so it seems we only find this gap in shouldChangeType + phi folding for the case when there is (1) an explicit datalayout without i1, (2) casting to i1 from a legal type, and (3) a phi with exactly 2 incoming casted operands (as Björn mentioned). Differential Revision: https://reviews.llvm.org/D29336 llvm-svn: 294066
* fix formatting; NFCSanjay Patel2017-01-311-7/+7
| | | | llvm-svn: 293652
* [InstCombine] Simplify gep (gep p, a), (b-a)Davide Italiano2017-01-191-19/+13
| | | | | | | | Patch by Andrea Canciani. Differential Revision: https://reviews.llvm.org/D27413 llvm-svn: 292506
* [PM] Introduce an analysis set used to preserve all analyses overChandler Carruth2017-01-151-2/+1
| | | | | | | | | | | | | | | a function's CFG when that CFG is unchanged. This allows transformation passes to simply claim they preserve the CFG and analysis passes to check for the CFG being preserved to remove the fanout of all analyses being listed in all passes. I've gone through and removed or cleaned up as many of the comments reminding us to do this as I could. Differential Revision: https://reviews.llvm.org/D28627 llvm-svn: 292054
* [PM] The assumption cache is fundamentally designed to be self-updating,Chandler Carruth2017-01-151-1/+0
| | | | | | | | | | | | | | mark it as never invalidated in the new PM. The old PM already required this to work, and after a discussion with Hal this seems to really be the only sensible answer. The cache gracefully degrades as the IR is mutated, and most things which do this should already be incrementally updating the cache. This gets rid of a bunch of logic preserving and testing the invalidation of this analysis. llvm-svn: 292039
* [PM] Fix instcombine's analysis preservation in the new pass manager toChandler Carruth2017-01-141-0/+3
| | | | | | | | | | | cover domtree and alias analysis. These are the pretty clear analyses that we would always want to survive this pass. To make these survive, we also need to preserve the assumption cache. Added a test that verifies the important bits of this preservation. llvm-svn: 292037
* [InstCombine] add a wrapper for a common pair of transforms; NFCISanjay Patel2017-01-101-7/+13
| | | | | | | Some of the callers are artificially limiting this transform to integer types; this should make it easier to incrementally remove that restriction. llvm-svn: 291620
* [Analysis] Centralize objectsize lowering logic.George Burgess IV2016-12-201-6/+3
| | | | | | | | | We're currently doing nearly the same thing for @llvm.objectsize in three different places: two of them are missing checks for overflow, and one of them could subtly break if InstCombine gets much smarter about removing alloc sites. Seems like a good idea to not do that. llvm-svn: 290214
* Revert @llvm.assume with operator bundles (r289755-r289757)Daniel Jasper2016-12-191-10/+19
| | | | | | | This creates non-linear behavior in the inliner (see more details in r289755's commit thread). llvm-svn: 290086
* Remove the AssumptionCacheHal Finkel2016-12-151-19/+10
| | | | | | | | | After r289755, the AssumptionCache is no longer needed. Variables affected by assumptions are now found by using the new operand-bundle-based scheme. This new scheme is more computationally efficient, and also we need much less code... llvm-svn: 289756
* [InstCombine] fix bug when offsetting case values of a switch (PR31260)Sanjay Patel2016-12-121-25/+15
| | | | | | | | | | | | | We could truncate the condition and then try to fold the add into the original condition value causing wrong case constants to be used. Move the offset transform ahead of the truncate transform and return after each transform, so there's no chance of getting confused values. Fix for: https://llvm.org/bugs/show_bug.cgi?id=31260 llvm-svn: 289442
* [InstCombine] clean up range-for-loops in visitSwitchInst(); NFCISanjay Patel2016-12-121-7/+7
| | | | llvm-svn: 289439
* IR: Change the gep_type_iterator API to avoid always exposing the "current" ↵Peter Collingbourne2016-12-021-2/+2
| | | | | | | | | | | | | type. Instead, expose whether the current type is an array or a struct, if an array what the upper bound is, and if a struct the struct type itself. This is in preparation for a later change which will make PointerType derive from Type rather than SequentialType. Differential Revision: https://reviews.llvm.org/D26594 llvm-svn: 288458
* [InstCombine] don't drop metadata in FoldOpIntoSelect()Sanjay Patel2016-11-261-3/+3
| | | | llvm-svn: 287980
* add and use isBitwiseLogicOp() helper function; NFCISanjay Patel2016-11-221-3/+2
| | | | llvm-svn: 287712
* Fix spelling mistakes in Transforms comments. NFC.Simon Pilgrim2016-11-201-1/+1
| | | | | | Identified by Pedro Giffuni in PR27636. llvm-svn: 287488
* [InstCombine] replace unreachable with assert and remove unreachable code; NFCISanjay Patel2016-11-161-20/+9
| | | | llvm-svn: 287147
* [InstCombine] fix formatting and add FIXMEs to ↵Sanjay Patel2016-11-161-11/+15
| | | | | | foldOperationIntoSelectOperand(); NFC llvm-svn: 287145
* [InstCombine] fix formatting of FoldOpIntoSelect(); NFCISanjay Patel2016-11-111-41/+43
| | | | llvm-svn: 286604
* [InstCombine] Fix constexpr issue in select combiningSimon Pilgrim2016-10-121-4/+5
| | | | | | | | As discussed by Andrea on PR30486, we have an unsafe cast to an Instruction type in the select combine which doesn't take into account that it could be a ConstantExpr instead. Differential Revision: https://reviews.llvm.org/D25466 llvm-svn: 284000
* [InstCombine] allow vector types for constant folding / computeKnownBits ↵Sanjay Patel2016-09-161-3/+4
| | | | | | | | | | | | | | | | (PR24942) computeKnownBits() already works for integer vectors, so allow vector types when calling that from InstCombine. I don't think the change to use m_APInt in computeKnownBits is strictly necessary because we do check for ConstantVector later, but it's more efficient to handle the splat case without needing to loop on vector elements. This should work with InstSimplify, but doesn't yet, so I made that a FIXME comment on the test for PR24942: https://llvm.org/bugs/show_bug.cgi?id=24942 Differential Revision: https://reviews.llvm.org/D24677 llvm-svn: 281777
* [InstCombine] Allow sinking from unique predecessor with multiple edgesJun Bum Lim2016-08-221-1/+1
| | | | | | | | | | | | Summary: We can allow sinking if the single user block has only one unique predecessor, regardless of the number of edges. Note that a switch statement with multiple cases can have the same destination. Reviewers: mcrosier, majnemer, spatel, reames Subscribers: reames, mcrosier, llvm-commits Differential Revision: https://reviews.llvm.org/D23722 llvm-svn: 279448
* Replace a few more "fall through" comments with LLVM_FALLTHROUGHJustin Bogner2016-08-171-1/+1
| | | | | | Follow up to r278902. I had missed "fall through", with a space. llvm-svn: 278970
* Consistently use FunctionAnalysisManagerSean Silva2016-08-091-1/+1
| | | | | | | | | | | Besides a general consistently benefit, the extra layer of indirection allows the mechanical part of https://reviews.llvm.org/D23256 that requires touching every transformation and analysis to be factored out cleanly. Thanks to David for the suggestion. llvm-svn: 278077
OpenPOWER on IntegriCloud