summaryrefslogtreecommitdiffstats
path: root/llvm/test/Transforms
Commit message (Collapse)AuthorAgeFilesLines
...
* Revert "[LV] Apply sink-after & interleave-groups as VPlan transformations ↵Gil Rapaport2019-11-081-35/+0
| | | | | | (NFCI)" This reverts commit 11ed1c0239fd51fd2f064311dc7725277ed0a994 - causes an assert failure.
* Reapply [LVI] Normalize pointer behaviorNikita Popov2019-11-081-1/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Fix cache invalidation by not guarding the dereferenced pointer cache erasure by SeenBlocks. SeenBlocks is only populated when actually caching a value in the block, which doesn't necessarily have to happen just because dereferenced pointers were calculated. ----- Related to D69686. As noted there, LVI currently behaves differently for integer and pointer values: For integers, the block value is always valid inside the basic block, while for pointers it is only valid at the end of the basic block. I believe the integer behavior is the correct one, and CVP relies on it via its getConstantRange() uses. The reason for the special pointer behavior is that LVI checks whether a pointer is dereferenced in a given basic block and marks it as non-null in that case. Of course, this information is valid only after the dereferencing instruction, or in conservative approximation, at the end of the block. This patch changes the treatment of dereferencability: Instead of including it inside the block value, we instead treat it as something similar to an assume (it essentially is a non-nullness assume) and incorporate this information in intersectAssumeOrGuardBlockValueConstantRange() if the context instruction is the terminator of the basic block. This happens either when determining an edge-value internally in LVI, or when a terminator was explicitly passed to getValueAt(). The latter case makes this change not fully NFC, because we can now fold terminator icmps based on the dereferencability information in the same block. This is the reason why I changed one JumpThreading test (it would optimize the condition away without the change). Of course, we do not want to recompute dereferencability on each intersectAssume call, so we need a new cache for this. The dereferencability analysis requires walking the entire basic block and computing underlying objects of all memory operands. This was previously done separately for each queried pointer value. In the new implementation (both because this makes the caching simpler, and because it is faster), I instead only walk the full BB once and cache all the dereferenced pointers. So the traversal is now performed only once per BB, instead of once per queried pointer value. I think the overall model now makes more sense than before, and there will be no more pitfalls due to differing integer/pointer behavior. Differential Revision: https://reviews.llvm.org/D69914
* Revert "[LVI] Normalize pointer behavior"Nikita Popov2019-11-081-2/+1
| | | | | | | This reverts commit 15bc4dc9a8949f9cffd46ec647baf0818d28fb28. clang-cmake-x86_64-sde-avx512-linux buildbot reported quite a few compile-time regressions in test-suite, will investigate.
* [LVI] Normalize pointer behaviorNikita Popov2019-11-081-1/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Related to D69686. As noted there, LVI currently behaves differently for integer and pointer values: For integers, the block value is always valid inside the basic block, while for pointers it is only valid at the end of the basic block. I believe the integer behavior is the correct one, and CVP relies on it via its getConstantRange() uses. The reason for the special pointer behavior is that LVI checks whether a pointer is dereferenced in a given basic block and marks it as non-null in that case. Of course, this information is valid only after the dereferencing instruction, or in conservative approximation, at the end of the block. This patch changes the treatment of dereferencability: Instead of including it inside the block value, we instead treat it as something similar to an assume (it essentially is a non-nullness assume) and incorporate this information in intersectAssumeOrGuardBlockValueConstantRange() if the context instruction is the terminator of the basic block. This happens either when determining an edge-value internally in LVI, or when a terminator was explicitly passed to getValueAt(). The latter case makes this change not fully NFC, because we can now fold terminator icmps based on the dereferencability information in the same block. This is the reason why I changed one JumpThreading test (it would optimize the condition away without the change). Of course, we do not want to recompute dereferencability on each intersectAssume call, so we need a new cache for this. The dereferencability analysis requires walking the entire basic block and computing underlying objects of all memory operands. This was previously done separately for each queried pointer value. In the new implementation (both because this makes the caching simpler, and because it is faster), I instead only walk the full BB once and cache all the dereferenced pointers. So the traversal is now performed only once per BB, instead of once per queried pointer value. I think the overall model now makes more sense than before, and there will be no more pitfalls due to differing integer/pointer behavior. Differential Revision: https://reviews.llvm.org/D69914
* [LICM] Support hosting of dynamic allocas out of loopsPhilip Reames2019-11-081-0/+168
| | | | | | | | | | | | This patch implements a correct, but not terribly useful, transform. In particular, if we have a dynamic alloca in a loop which is guaranteed to execute, and provably not captured, we hoist the alloca out of the loop. The capture tracking is needed so that we can prove that each previous stack region dies before the next one is allocated. The transform decreases the amount of stack allocation needed by a linear factor (e.g. the iteration count of the loop). Now, I really hope no one is actually using dynamic allocas. As such, why this patch? Well, the actual problem I'm hoping to make progress on is allocation hoisting. There's a large draft patch out for review (https://reviews.llvm.org/D60056), and this patch was the smallest chunk of testable functionality I could come up with which takes a step vaguely in that direction. Once this is in, it makes motivating the changes to capture tracking mentioned in TODOs testable. After that, I hope to extend this to trivial malloc free regions (i.e. free dominating all loop exits) and allocation functions for GCed languages. Differential Revision: https://reviews.llvm.org/D69227
* [LICM] Hoisting of widenable conditions out of loopsPhilip Reames2019-11-081-7/+42
| | | | | | The change itself is straight forward and obvious, but ... there's an existing test checking for exactly the opposite. Both I and Artur think this is simply conservatism in the initial implementation. If anyone bisects a problem to this, a counter example will be very interesting. Differential Revision: https://reviews.llvm.org/D69907
* [LV] Apply sink-after & interleave-groups as VPlan transformations (NFCI)Gil Rapaport2019-11-081-0/+35
| | | | | | | | This recommits 100e797adb433724a17c9b42b6533cd634cb796b (reverted in 009e032634b3bd7fc32071ac2344b12142286477 for failing an assert). While the root cause was independently reverted in eaff3004019f97c64c88ab76da6b25106b659b30, this commit includes a LIT to make sure IVDescriptor's SinkAfter logic does not try to sink branch instructions.
* [InstCombine] Don't transform bitcasts between x86_mmx and v1i64 into ↵Craig Topper2019-11-071-4/+2
| | | | | | | | | | insertelement/extractelement x86_mmx is conceptually a vector already. Don't introduce an extra conversion between it and scalar i64. I'm using VectorType::isValidElementType which checks for floating point, integer, and pointers to hopefully make this more readable than just blacklisting x86_mmx. Differential Revision: https://reviews.llvm.org/D69964
* [InstCombine] auto-generate complete checks; NFCSanjay Patel2019-11-071-10/+9
|
* [InstCombine] Add test cases to show bad canonicalization of bitcasts ↵Craig Topper2019-11-071-0/+19
| | | | | | | | | | | | | between x86_mmx and <1 x i64>. As the test cases show, we end up with an insert/extract and a bitcast to/from i64. x86_mmx is for some purposes conceptually a vector. We shouldn't be adding scalar conversions around it. Since _m64 is defined as <1 x i64> and intrinsics use x86_mmx as their input/output these extra scalar operations prevent the X86 backend from generating good code especially on 32-bit targets where i64 gets split.
* Wrong debug info generated at -O2 (-O0 is correct)Vedant Kumar2019-11-074-5/+62
| | | | | | | | | | | | | | | | Instcombiner pass was erasing trivially dead instruction without updating dependent llvm.dbg.value. which was not showing programmer current state of variables while debugging. As a part of this fix I did following, Iterate throught all the users (llvm.dbg) of a instruction which is trivially dead and set each if them undef, Before deleting the instruction. Now user will see optimized out, when try to print those variables. This fixes https://bugs.llvm.org/show_bug.cgi?id=43893 This is my first fix to llvm. Patch by kamlesh kumar! Differential Revision: https://reviews.llvm.org/D69809
* [InstCombine] canonicalize shift+logic+shift to reduce dependency chainSanjay Patel2019-11-072-31/+31
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | shift (logic (shift X, C0), Y), C1 --> logic (shift X, C0+C1), (shift Y, C1) This is an IR translation of an existing SDAG transform added here: rL370617 So we again have 9 possible patterns with a commuted IR variant of each pattern: https://rise4fun.com/Alive/VlI https://rise4fun.com/Alive/n1m https://rise4fun.com/Alive/1Vn Part of the motivation is to allow easier recognition and subsequent canonicalization of bswap patterns as discussed in PR43146: https://bugs.llvm.org/show_bug.cgi?id=43146 We had to delay this transform because it used to allow the SLP vectorizer to create awful reductions out of simple load-combines. That problem was fixed with: rL375025 (we'll bring back load combining in IR someday...) The backend is also better equipped to deal with these patterns now using hooks like TLI.getShiftAmountThreshold(). The only remaining potential controversy is that the -reassociate pass tends to reverse this kind of pattern (to help GVN?). But since -reassociate doesn't do anything with these specific patterns, there is no conflict currently. Finally, there's a new pass proposal at D67383 for general tree-height-reduction reassociation, and it could use a cost model to decide how to optimally rearrange these kinds of ops for a target. That patch appears to be stalled. Differential Revision: https://reviews.llvm.org/D69842
* [ConstantRange][LVI] Use overflow flags from `sub` to constrain the rangeRoman Lebedev2019-11-071-6/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: This notably improves non-negativity deduction: ``` | statistic | old | new | delta | % change | | correlated-value-propagation.NumAShrs | 209 | 227 | 18 | 8.6124% | | correlated-value-propagation.NumAddNSW | 4972 | 4988 | 16 | 0.3218% | | correlated-value-propagation.NumAddNUW | 7141 | 7148 | 7 | 0.0980% | | correlated-value-propagation.NumAddNW | 12113 | 12136 | 23 | 0.1899% | | correlated-value-propagation.NumAnd | 442 | 445 | 3 | 0.6787% | | correlated-value-propagation.NumNSW | 7160 | 7176 | 16 | 0.2235% | | correlated-value-propagation.NumNUW | 13306 | 13316 | 10 | 0.0752% | | correlated-value-propagation.NumNW | 20466 | 20492 | 26 | 0.1270% | | correlated-value-propagation.NumSDivs | 207 | 212 | 5 | 2.4155% | | correlated-value-propagation.NumSExt | 6279 | 6679 | 400 | 6.3704% | | correlated-value-propagation.NumSRems | 28 | 29 | 1 | 3.5714% | | correlated-value-propagation.NumShlNUW | 2793 | 2796 | 3 | 0.1074% | | correlated-value-propagation.NumShlNW | 3964 | 3967 | 3 | 0.0757% | | correlated-value-propagation.NumUDivs | 353 | 358 | 5 | 1.4164% | | instcount.NumAShrInst | 13763 | 13741 | -22 | -0.1598% | | instcount.NumAddInst | 277349 | 277348 | -1 | -0.0004% | | instcount.NumLShrInst | 27437 | 27463 | 26 | 0.0948% | | instcount.NumOrInst | 102677 | 102678 | 1 | 0.0010% | | instcount.NumSDivInst | 8732 | 8727 | -5 | -0.0573% | | instcount.NumSExtInst | 80872 | 80468 | -404 | -0.4996% | | instcount.NumSRemInst | 1679 | 1678 | -1 | -0.0596% | | instcount.NumTruncInst | 62154 | 62153 | -1 | -0.0016% | | instcount.NumUDivInst | 2526 | 2527 | 1 | 0.0396% | | instcount.NumURemInst | 1589 | 1590 | 1 | 0.0629% | | instcount.NumZExtInst | 69405 | 69809 | 404 | 0.5821% | | instcount.TotalInsts | 7439575 | 7439574 | -1 | 0.0000% | ``` Reviewers: nikic, reames, spatel Reviewed By: nikic Subscribers: hiraditya, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D69942
* [SLP] allow forming 2-way reduction patternsSanjay Patel2019-11-071-10/+9
| | | | | | | | | | | | | | | | | | | | | | | | | We have a vector compare reduction problem seen in PR39665 comment 2: https://bugs.llvm.org/show_bug.cgi?id=39665#c2 Or slightly reduced here: define i1 @cmp2(<2 x double> %a0) { %a = fcmp ogt <2 x double> %a0, <double 1.0, double 1.0> %b = extractelement <2 x i1> %a, i32 0 %c = extractelement <2 x i1> %a, i32 1 %d = and i1 %b, %c ret i1 %d } SLP would not attempt to turn this into a vector reduction because there is an artificial lower limit on that transform. We can not completely remove that limit without inducing regressions though, so this patch just hacks an extra attempt at creating a 2-way reduction to the end of the analysis. As shown in the test file, we are still not getting some of the motivating cases, so follow-on patches will be needed to solve those cases. Differential Revision: https://reviews.llvm.org/D59710
* [NFC][CVP] Add some tests for `sub` with preexisting no-wrap flagsRoman Lebedev2019-11-071-0/+216
| | | | We can use those to further limit the ranges in LVI.
* Revert f0c2a5a "[LV] Generalize conditions for sinking instrs for first ↵Hans Wennborg2019-11-071-245/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | order recurrences." It broke Chromium, causing "Instruction does not dominate all uses!" errors. See https://bugs.chromium.org/p/chromium/issues/detail?id=1022297#c1 for a reproducer. > If the recurrence PHI node has a single user, we can sink any > instruction without side effects, given that all users are dominated by > the instruction computing the incoming value of the next iteration > ('Previous'). We can sink instructions that may cause traps, because > that only causes the trap to occur later, but not on any new paths. > > With the relaxed check, we also have to make sure that we do not have a > direct cycle (meaning PHI user == 'Previous), which indicates a > reduction relation, which potentially gets missed by > ReductionDescriptor. > > As follow-ups, we can also sink stores, iff they do not alias with > other instructions we move them across and we could also support sinking > chains of instructions and multiple users of the PHI. > > Fixes PR43398. > > Reviewers: hsaito, dcaballe, Ayal, rengolin > > Reviewed By: Ayal > > Differential Revision: https://reviews.llvm.org/D69228
* Keep import function list for inlinee profile updateWenlei He2019-11-062-0/+83
| | | | | | | | | | | | | Summary: When adjusting function entry counts after inlining, Funciton::setEntryCount is called without providing an import function list. The side effect of that is the previously set import function list will be dropped. The import function list is used by ThinLTO to help import hot cross module callee for LTO inlining, so dropping that during ThinLTO pre-link may adversely affect LTO inlining. The fix is to keep the list while updating entry counts for inlining. Reviewers: wmi, davidxl, tejohnson Subscribers: mehdi_amini, hiraditya, dexonsmith, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D69736
* AMDGPU: Select global atomicrmw faddMatt Arsenault2019-11-061-0/+145
| | | | This only works if there is no use of the return value.
* Temporarily Revert:Eric Christopher2019-11-0620-875/+407
| | | | | | | | | | | | | | | | | "[SLP] Generalization of stores vectorization." "[SLP] Fix -Wunused-variable. NFC" "[SLP] Vectorize jumbled stores." As they're causing significant (10-30x) compile time regressions on vectorizable code. The primary cause of the compile-time regression is f228b5371647f471853c5fb3e6719823a42fe451. This reverts commits: f228b5371647f471853c5fb3e6719823a42fe451 5503455ccb3f5fcedced158332c016c8d3a7fa81 21d498c9c0f32dcab5bc89ac593aa813b533b43a
* [LoopPred] Enable new transformation by defaultPhilip Reames2019-11-062-6/+3
| | | | | | | | The basic idea of the transform is to convert variant loop exit conditions into invariant exit conditions by changing the iteration on which the exit is taken when we know that the trip count is unobservable. See the original patch which introduced the code for a more complete explanation. The individual parts of this have been reviewed, the result has been fuzzed, and then further analyzed by hand, but despite all of that, I will not be suprised to see breakage here. If you see problems, please don't hesitate to revert - though please do provide a test case. The most likely class of issues are latent SCEV bugs and without a reduced test case, I'll be essentially stuck on reducing them. (Note: A bunch of tests were opted out of the new transform to preserve coverage. That landed in a previous commit to simplify revert cycles if they turn out to be needed.)
* [LoopPred] Selectively disable to preserve test casesPhilip Reames2019-11-0612-12/+12
| | | | | | I'm about to enable the new loop predication transform by default. It has the effect of completely destroying many read only loops - which happen to be a super common idiom in our test cases. So as to preserve test coverage of other transforms, disable the new transform where it would cause sharp test coverage regressions. (This is semantically part of the enabling commit. It's committed separate to ease revert if the actual flag flip gets reverted.)
* [WC] Fix a subtle bug in our definition of widenable branchPhilip Reames2019-11-063-16/+65
| | | | | | | | | | | | We had a subtle, but nasty bug in our definition of a widenable branch, and thus in the transforms which used that utility. Specifically, we returned true for any branch which included a widenable condition within it's condition, regardless of whether that widenable condition also had other uses. The problem is that the result of the WC() call is defined to be one particular value. As such, all users must agree as to what that value is. If we widen a branch without also updating *all other users* of the WC in the same way, we have broken the required semantics. Most of the textual diff is updating existing transforms not to leave dead uses hanging around. They're largely NFC as the dead instructions would be immediately deleted by other passes. The reason to make these changes is so that the transforms preserve the widenable branch form. In practice, we don't get bitten by this only because it isn't profitable to CSE WC() calls and the lowering pass from guards uses distinct WC calls per branch. Differential Revision: https://reviews.llvm.org/D69916
* [LoopUnroll] countToEliminateCompares(): fix handling of [in]equality ↵Roman Lebedev2019-11-061-22/+172
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | predicates (PR43840) Summary: I believe this bisects to https://reviews.llvm.org/D44983 (`[LoopUnroll] Only peel if a predicate becomes known in the loop body.`) While that revision did contain tests that showed arguably-subpar peeling for [in]equality predicates that [not] happen in the middle of the loop, it also disabled peeling for the *first* loop iteration, because latch would be canonicalized to [in]equality comparison.. That was intentional as per https://reviews.llvm.org/D44983#1059583. I'm not 100% sure that i'm using correct checks here, but this fix appears to be going in the right direction.. Let me know if i'm missing some checks here.. Fixes [[ https://bugs.llvm.org/show_bug.cgi?id=43840 | PR43840 ]]. Reviewers: fhahn, mkazantsev, efriedma Reviewed By: fhahn Subscribers: xbolva00, hiraditya, zzheng, llvm-commits, fhahn Tags: #llvm Differential Revision: https://reviews.llvm.org/D69617
* [NFC][LoopUnroll] Update test coverage for peeling w/ inequality predicatesRoman Lebedev2019-11-061-5/+89
|
* [AMDGPU] Improve code size cost model (part 2)dfukalov2019-11-061-1/+1
| | | | | | | | | | | | | | Summary: Added estimations for ShuffleVector, some cast and arithmetic instructions Reviewers: rampitec Reviewed By: rampitec Subscribers: arsenm, kzhuravl, jvesely, wdng, nhaehnle, yaxunl, dstuttard, tpr, t-tye, hiraditya, zzheng, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D69629
* [TTI][LV] preferPredicateOverEpilogueSjoerd Meijer2019-11-062-2/+82
| | | | | | | | | | | | | | | | | We have two ways to steer creating a predicated vector body over creating a scalar epilogue. To force this, we have 1) a command line option and 2) a pragma available. This adds a third: a target hook to TargetTransformInfo that can be queried whether predication is preferred or not, which allows the vectoriser to make the decision without forcing it. While this change behaves as a non-functional change for now, it shows the required TTI plumbing, usage of this new hook in the vectoriser, and the beginning of an ARM MVE implementation. I will follow up on this with: - a complete MVE implementation, see D69845. - a patch to disable this, i.e. we should respect "vector_predicate(disable)" and its corresponding loophint. Differential Revision: https://reviews.llvm.org/D69040
* [SLP] add tests for 2-wide reductions; NFCSanjay Patel2019-11-051-2/+115
|
* [ObjC][ARC] Ignore lifetime markers between *ReturnValue callsFrancis Visoiu Mistrih2019-11-051-4/+0
| | | | | | | | | | | | | | | | | | | | | | When eliminating a pair of `llvm.objc.autoreleaseReturnValue` followed by `llvm.objc.retainAutoreleasedReturnValue` we need to make sure that the instructions in between are safe to ignore. Other than bitcasts and useless GEPs, it's also safe to ignore lifetime markers for both static allocas (lifetime.start/lifetime.end) and dynamic allocas (stacksave/stackrestore). These get added by the inliner as part of the return sequence and can prevent the transformation from happening in practice. Differential Revision: https://reviews.llvm.org/D69833
* [NFC][ObjC][ARC] Add tests for OptimizeRetainRVCallFrancis Visoiu Mistrih2019-11-051-0/+68
| | | | | Add tests for bitcasts + zero GEPs, and pre-commit tests for lifetime markers.
* [InstCombine] add tests for shift-logic-shift; NFCSanjay Patel2019-11-051-0/+171
| | | | | | This is based on existing CodeGen test files for x86 and AArch64. The corresponding potential transform is shown in: rL370617
* [LoopUnroll] peel-loop-conditions.ll: add some 'is even/odd' peeling testsRoman Lebedev2019-11-051-0/+98
|
* [InstCombine] dropRedundantMaskingOfLeftShiftInput(): truncation (PR42563)Roman Lebedev2019-11-0511-108/+108
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: That fold keeps growing and growing :( I think this may be one of the last pieces for it. Since D67677/D67725, the fold knowns the general form of the pattern - where some masking is needed: https://rise4fun.com/Alive/F5R https://rise4fun.com/Alive/gslRa But there is one more huge piece missing - if you are extracting some bits, it is not impossible that the origin is wider than the extraction, i.e. there may be a truncation. And we don't deal with that yet. But we can, and the generalization remains fully identical: https://rise4fun.com/Alive/Uar https://rise4fun.com/Alive/5SW After a preparatory cleanup i think the diff looks rather clean. One missing piece is that in some patterns (especially pat. b), `-1` only needs to be `-1` in final type, but that is for later.. https://bugs.llvm.org/show_bug.cgi?id=42563 Reviewers: spatel, nikic Reviewed By: spatel Subscribers: hiraditya, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D69125
* Recommit "[HardwareLoops] Optimisation remarks"Sjoerd Meijer2019-11-051-3/+22
| | | | | | | | | With a few things fixed: - initialisaiton of the optimisation remark pass (this was causing the buildbot failures on PPC), - a test case. Differential Revision: https://reviews.llvm.org/D69660
* [IR] Add Freeze instructionaqjune2019-11-051-3/+3
| | | | | | | | | | | | | | | | | | Summary: - Define Instruction::Freeze, let it be UnaryOperator - Add support for freeze to LLLexer/LLParser/BitcodeReader/BitcodeWriter The format is `%x = freeze <ty> %v` - Add support for freeze instruction to llvm-c interface. - Add m_Freeze in PatternMatch. - Erase freeze when lowering IR to SelDag. Reviewers: deadalnix, hfinkel, efriedma, lebedev.ri, nlopes, jdoerfert, regehr, filcab, delcypher, whitequark Reviewed By: lebedev.ri, jdoerfert Subscribers: jfb, kristof.beyls, hiraditya, lebedev.ri, steven_wu, dexonsmith, xbolva00, delcypher, spatel, regehr, trentxintong, vsk, filcab, nlopes, mehdi_amini, deadalnix, llvm-commits Differential Revision: https://reviews.llvm.org/D29011
* [SimplifyCFG] Use a (trivially) dominanting widenable branch to remove later ↵Philip Reames2019-11-041-0/+316
| | | | | | | | | | slow path blocks This transformation is a variation on the GuardWidening transformation we have checked in as it's own pass. Instead of focusing on merge (i.e. hoisting and simplifying) two widenable branches, this transform makes the observation that simply removing a second slowpath block (by reusing an existing one) is often a very useful canonicalization. This may lead to later merging, or may not. This is a useful generalization when the intermediate block has loads whose dereferenceability is hard to establish. As noted in the patch, this can be generalized further, and will be. Differential Revision: https://reviews.llvm.org/D69689
* Recommit "[CodeView] Add option to disable inline line tables."Amy Huang2019-11-041-0/+99
| | | | | | | | | | | | This reverts commit 004ed2b0d1b86d424643ffc88fce20ad8bab6804. Original commit hash 6d03890384517919a3ba7fe4c35535425f278f89 Summary: This adds a clang option to disable inline line tables. When it is used, the inliner uses the call site as the location of the inlined function instead of marking it as an inline location with the function location. https://reviews.llvm.org/D67723
* [SLP]Fix PR43799: Crash on different sizes of GEP indices.Alexey Bataev2019-11-041-0/+23
| | | | | | | | | | | | | | | Summary: If the GEP instructions are going to be vectorized, the indices in those GEP instructions must be of the same type. Otherwise, the compiler may crash when trying to build the vector constant. Reviewers: RKSimon, spatel Subscribers: hiraditya, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D69627
* [InstSimplify] use FMF to improve fcmp+select foldSanjay Patel2019-11-041-24/+8
| | | | | This is part of a series of patches needed to solve PR39535: https://bugs.llvm.org/show_bug.cgi?id=39535
* [InstSimplify] add more tests for fcmp+select; NFCSanjay Patel2019-11-041-8/+36
| | | | | | The easy code fix won't catch non-canonical mismatched constant patterns, so adding extra coverage for those in case we decide that's important (but seems unlikely).
* [InstSimplify] add more tests for fcmp+select; NFCSanjay Patel2019-11-041-0/+156
| | | | | The addition of FMF for select allows more folding for these kinds of patterns.
* [LV] Generalize conditions for sinking instrs for first order recurrences.Florian Hahn2019-11-021-0/+245
| | | | | | | | | | | | | | | | | | | | | | | | | If the recurrence PHI node has a single user, we can sink any instruction without side effects, given that all users are dominated by the instruction computing the incoming value of the next iteration ('Previous'). We can sink instructions that may cause traps, because that only causes the trap to occur later, but not on any new paths. With the relaxed check, we also have to make sure that we do not have a direct cycle (meaning PHI user == 'Previous), which indicates a reduction relation, which potentially gets missed by ReductionDescriptor. As follow-ups, we can also sink stores, iff they do not alias with other instructions we move them across and we could also support sinking chains of instructions and multiple users of the PHI. Fixes PR43398. Reviewers: hsaito, dcaballe, Ayal, rengolin Reviewed By: Ayal Differential Revision: https://reviews.llvm.org/D69228
* [Attributor][NFCI] Distinguish optional and required dependencesJohannes Doerfert2019-11-027-8/+8
| | | | | | | | | | | | | | | | | | Dependences between two abstract attributes SRC and TRG come naturally in two flavors: Either (1) "some" information of SRC is *required* for TRG to derive information, or (2) SRC is just an *optional* way for TRG to derive information. While it is not strictly necessary to distinguish these types explicitly, it can help us to converge faster, in terms of iterations, and also cut down the number of `AbstractAttribute::update` calls. As far as I can tell, we only use optional dependences for liveness so far but that might change in the future. With this change the Attributor can be informed about the "dependence class" and it will perform appropriate actions when an Attribute is set to an invalid state, thus one that cannot be used by others to derive information from.
* NoFree argument attribute.Stefan Stipanovic2019-11-0219-173/+215
| | | | | | | | | | | | Summary: Deducing nofree atrribute for function arguments. Reviewers: jdoerfert Subscribers: hiraditya, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D67886
* Revert "NoFree argument attribute."Stefan Stipanovic2019-11-0218-211/+169
| | | | This reverts commit c12efa2ed0547f7f9f8fba0ad7a76a4cb08bf53a.
* NoFree argument attribute.Stefan Stipanovic2019-11-0218-169/+211
| | | | | | | | | | | | Summary: Deducing nofree atrribute for function arguments. Reviewers: jdoerfert Subscribers: hiraditya, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D67886
* Revert BCmp Loop Idiom recognition transform (PR43870)Roman Lebedev2019-11-024-3148/+0
| | | | | | | | | | | | | | | | | As discussed in https://bugs.llvm.org/show_bug.cgi?id=43870, this transform is missing a crucial legality check: the old (non-countable) loop would early-return upon first mismatch, but there is no such guarantee for bcmp/memcmp. We'd need to ensure that [PtrA, PtrA+NBytes) and [PtrB, PtrB+NBytes) are fully dereferenceable memory regions. But that would limit the transform to constant loop trip counts and would further cripple it because dereferenceability analysis is *very* partial. Furthermore, even if all that is done, every single test would need to be rewritten from scratch. So let's just give up.
* [Attributor] Ignore BlockAddress users in call site traversalJohannes Doerfert2019-11-021-0/+25
| | | | | | | BlockAddress users will not "call" the function so they do not qualify as call sites in the first place. When we delete a function with BlockAddress users we need to first remove the body so they are properly discarded.
* [AbstractCallSite][FIX] Correct faulty assertionJohannes Doerfert2019-11-021-0/+1
| | | | | | When the Attributor run on the IPConstantProp test case for multiple callbacks it triggered a faulty assertion in the AbstractCallSite implementation. The callee can well be at argument position 0.
* [Attributor][FIX] Do not try to cast if a cast is not requiredJohannes Doerfert2019-11-021-9/+15
| | | | | | | | | When we replace constant returns at the call site we did issue a cast in the hopes it would be a no-op if the types are equal. Turns out that is not the case and we have to check it ourselves first. Reused an IPConstantProp test for coverage. No functional change to the test wrt. IPConstantProp.
* [Attributor][FIX] Transform invoke of nounwind to call + br %normal_destJohannes Doerfert2019-11-021-3/+44
| | | | | | | | | Even if the invoked function may-return, we can replace it with a call and branch if it is nounwind. We had almost everything in place to do this but did not which actually caused a crash when we removed the landingpad from the actually dead unwind block. Exposed by the IPConstantProp tests.
OpenPOWER on IntegriCloud