summaryrefslogtreecommitdiffstats
path: root/llvm/lib/Transforms
Commit message (Collapse)AuthorAgeFilesLines
* Range-ify for loop; NFCGeorge Burgess IV2018-05-051-2/+1
| | | | llvm-svn: 331582
* Fix a bunch of places where operator-> was used directly on the return from ↵Craig Topper2018-05-053-7/+6
| | | | | | | | | | dyn_cast. Inspired by r331508, I did a grep and found these. Mostly just change from dyn_cast to cast. Some cases also showed a dyn_cast result being converted to bool, so those I changed to isa. llvm-svn: 331577
* LowerTypeTests: Fix non-determinism in code that handles icall branch funnels.Peter Collingbourne2018-05-051-13/+26
| | | | | | | | | This was exposed by enabling expensive checks, which causes llvm::sort to sort randomly. Differential Revision: https://reviews.llvm.org/D45901 llvm-svn: 331573
* [LICM] Compute a must execute property for the prefix of the header as we goPhilip Reames2018-05-041-3/+14
| | | | | | | | Computing this property within the existing walk ensures that the cost is linear with the size of the block. If we did this from within isGuaranteedToExecute, it would be quadratic without some very fancy caching. This allows us to reliably catch a hoistable instruction within a header which may throw at some point *after* our hoistable instruction. It doesn't do anything for non-header cases, but given how common single block loops are, this seems very worthwhile. llvm-svn: 331557
* [ObjCARC] Account for catchswitch in bitcast insertionShoaib Meenai2018-05-041-4/+17
| | | | | | | | | | | | | A catchswitch is both a pad and a terminator, meaning it must be the only non-phi instruction in its basic block. When we're inserting a bitcast in the incoming basic block for a phi, if that incoming block is a catchswitch, we should go up the dominator tree to find a valid insertion point rather than attempting to insert before the catchswitch (which would result in invalid IR). Differential Revision: https://reviews.llvm.org/D46412 llvm-svn: 331548
* [LoopIdiomRecognize] Don't create an IRBuilder just to call getTrue/getFalse.Craig Topper2018-05-041-2/+2
| | | | | | We can call the methods in ConstantInt directly. We just need a context. llvm-svn: 331542
* [IRCE] Fix misuse of dyn_cast which leads to UBMax Kazantsev2018-05-041-2/+3
| | | | llvm-svn: 331508
* [LoopIdiomRecognize] Replace more unchecked dyn_casts with cast.Craig Topper2018-05-041-4/+4
| | | | | | Two of these are immediately dereferenced on the next line. The other two are passed immediately to the IRBuilder constructor which can't handle a nullptr. llvm-svn: 331500
* [LoopIdiomRecognize] Use a regular array instead of a SmallVector and ↵Craig Topper2018-05-041-2/+1
| | | | | | explicit ArrayRef. llvm-svn: 331499
* [LoopIdiomRecognize] Turn two uncheck dyn_casts into regular casts.Craig Topper2018-05-041-2/+2
| | | | | | These are casts on users of a PHINode to Instruction. I think since PHINode is an Instruction any users would also be Instructions. At least a cast will give us an assertion if its wrong. llvm-svn: 331498
* [InstCombine] refine select-of-constants to bitwise opsSanjay Patel2018-05-031-57/+34
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Add logic for the special case when a cmp+select can clearly be reduced to just a bitwise logic instruction, and remove an over-reaching chunk of general purpose bit magic. The primary goal is to remove cases where we are not improving the IR instruction count when doing these select transforms, and in all cases here that is true. In the motivating 3-way compare tests, there are further improvements because we can combine/propagate select values (not sure if that belongs in instcombine, but it's there for now). DAGCombiner has folds to turn some of these selects into bit magic, so there should be no difference in the end result in those cases. Not all constant combinations are handled there yet, however, so it is possible that some targets will see more cmov/csel codegen with this change in IR canonicalization. Ideally, we'll go further to *not* turn selects into multiple logic/math ops in instcombine, and we'll canonicalize to selects. But we should make sure that this step does not result in regressions first (and if it does, we should fix those in the backend). The general direction for this change was discussed here: http://lists.llvm.org/pipermail/llvm-dev/2016-September/105373.html http://lists.llvm.org/pipermail/llvm-dev/2017-July/114885.html Alive proofs for the new bit magic: https://rise4fun.com/Alive/XG7 Differential Revision: https://reviews.llvm.org/D46086 llvm-svn: 331486
* perform DSE through launder.invariant.groupPiotr Padlewski2018-05-031-5/+5
| | | | | | | | | | | | | | | | | Summary: Alias Analysis knows that llvm.launder.invariant.group returns pointer that mustalias argument, but this information wasn't used, therefor we didn't DSE through launder.invariant.group Reviewers: chandlerc, dberlin, bogner, hfinkel, efriedma Reviewed By: dberlin Subscribers: amharc, llvm-commits, nlewycky, rsmith Differential Revision: https://reviews.llvm.org/D31581 llvm-svn: 331449
* [LoopIdiomRecognize] When looking for 'x & (x -1)' for popcnt, make sure the ↵Craig Topper2018-05-031-1/+1
| | | | | | left hand side of the 'and' matches the left hand side of the 'subtract' llvm-svn: 331437
* [LoopIdiomRecognize] Remove unnecessary cast from BinaryOperator to ↵Craig Topper2018-05-031-4/+3
| | | | | | | | Instruction. NFC BinaryOperator is a sub class of Instruction. We don't need an explicit cast back to Instruction. llvm-svn: 331432
* [ObjCARC] Convert an if to an early continue. NFCShoaib Meenai2018-05-031-29/+29
| | | | | | | | This reduces nesting and makes the logic slightly easier to follow. Differential Revision: https://reviews.llvm.org/D46371 llvm-svn: 331422
* [gcov] Switch to an explicit if clunky array to satisfy some compilersChandler Carruth2018-05-031-9/+8
| | | | | | | on various build bots that are unhappy with using makeArrayRef with an initializer list. llvm-svn: 331418
* [GCOV] Emit the writeout function as nested loops of global data.Chandler Carruth2018-05-021-35/+186
| | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: Prior to this change, LLVM would in some cases emit *massive* writeout functions with many 10s of 1000s of function calls in straight-line code. This is a very wasteful way to represent what are fundamentally loops and creates a number of scalability issues. Among other things, register allocating these calls is extremely expensive. While D46127 makes this less severe, we'll still run into scaling issues with this eventually. If not in the compile time, just from the code size. Now the pass builds up global data structures modeling the inputs to these functions, and simply loops over the data structures calling the relevant functions with those values. This ensures that the code size is a fixed and only data size grows with larger amounts of coverage data. A trivial change to IRBuilder is included to make it easier to build the constants that make up the global data. Reviewers: wmi, echristo Subscribers: sanjoy, mcrosier, llvm-commits, hiraditya Differential Revision: https://reviews.llvm.org/D46357 llvm-svn: 331407
* [reassociate] Fix excessive revisits when processing long chains of ↵Daniel Sanders2018-05-021-7/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | reassociatable instructions. Summary: Some of our internal testing detected a major compile time regression which I've tracked down to: r278938 - Revert "Reassociate: Reprocess RedoInsts after each inst". It appears that processing long chains of reassociatable instructions causes non-linear (potentially exponential) growth in the number of times an instruction is revisited. For example, the included test revisits instructions 220 times in a 20-instruction test. It appears that r278938 reversed the order instructions were visited and that this is preventing scheduled revisits from being cancelled as a result of visiting the instructions naturally during normal processing. However, simply reversing the order also harmed the generated code. Upon closer inspection, it was discovered that revisits occurred in the opposite order to the first pass (Thanks to escha for spotting that). This patch makes the revisit order consistent with the first pass which allows more revisits to be cancelled. This does appear to have a small impact on the generated code in few cases but it significantly reduces compile-time. After this patch, our internal test that was most affected by the regression dropped from ~2 million revisits to ~4k resulting in Reassociate having 0.46% of the runtime it had before (99.54% improvement). Here's the summaries reported by lnt for the LLVM test-suite with --benchmarking-only: | metric | geomean before patch | geomean after patch | delta | | ----- | ----- | ----- | ----- | | compile time | 0.1956 | 0.1261 | -35.54% | | execution time | 0.3240 | 0.3237 | - | | code size | 7365.4459 | 7365.6079 | - | The results have a few wins and losses on compile-time, mostly in the +/- 2.5% range. There was one outlier though: | Performance Regressions - compile_time | Δ | Previous | Current | | MultiSource/Benchmarks/ASC_Sequoia/CrystalMk/CrystalMk | 9.82% | 2.0473 | 2.2483 | Reviewers: javed.absar, dberlin Reviewed By: dberlin Subscribers: kristof.beyls, llvm-commits Differential Revision: https://reviews.llvm.org/D45734 llvm-svn: 331381
* Fix '32-bit shift implicitly converted to 64 bits' warning by using ↵Simon Pilgrim2018-05-021-1/+1
| | | | | | APInt::setBit instead. llvm-svn: 331359
* [LoopInterchange] Update some loops to use range base for loops (NFC).Florian Hahn2018-05-021-30/+24
| | | | llvm-svn: 331342
* [AggressiveInstCombine] convert a chain of 'or-shift' bits into masked compareSanjay Patel2018-05-011-21/+94
| | | | | | | | | | | | | | | | | | | | | and (or (lshr X, C), ...), 1 --> (X & C') != 0 I initially thought about implementing the minimal pattern in instcombine as mentioned here: https://bugs.llvm.org/show_bug.cgi?id=37098#c6 ...but we need to do better to catch the more general sequence from the motivating test (more than 2 bits in the compare). And a test-suite run with statistics showed that this pattern only happened 2 times currently. It would potentially happen more often if reassociation worked better (D45842), but it's probably still not too frequent? This is small enough that I didn't see a need to create a whole new class/file within AggressiveInstCombine. There are likely other relatively small matchers like what was discussed in D44266 that would slide under foldUnusualPatterns() (name suggestions welcome). We could potentially also consolidate matchers for ctpop, bswap, etc under here. Differential Revision: https://reviews.llvm.org/D45986 llvm-svn: 331311
* Remove @brief commands from doxygen comments, too.Adrian Prantl2018-05-015-12/+12
| | | | | | | | | | | | | | | | | This is a follow-up to r331272. We've been running doxygen with the autobrief option for a couple of years now. This makes the \brief markers into our comments redundant. Since they are a visual distraction and we don't want to encourage more \brief markers in new code either, this patch removes them all. Patch produced by for i in $(git grep -l '\@brief'); do perl -pi -e 's/\@brief //g' $i & done https://reviews.llvm.org/D46290 llvm-svn: 331275
* Remove \brief commands from doxygen comments.Adrian Prantl2018-05-0163-493/+493
| | | | | | | | | | | | | | | | We've been running doxygen with the autobrief option for a couple of years now. This makes the \brief markers into our comments redundant. Since they are a visual distraction and we don't want to encourage more \brief markers in new code either, this patch removes them all. Patch produced by for i in $(git grep -l '\\brief'); do perl -pi -e 's/\\brief //g' $i & done Differential Revision: https://reviews.llvm.org/D46290 llvm-svn: 331272
* [LV] Preserve inbounds on created GEPsDaniel Neilson2018-05-011-3/+22
| | | | | | | | | | | | | | | | | | | Summary: This is a fix for PR23997. The loop vectorizer is not preserving the inbounds property of GEPs that it creates. This is inhibiting some optimizations. This patch preserves the inbounds property in the case where a load/store is being fed by an inbounds GEP. Reviewers: mkuper, javed.absar, hsaito Reviewed By: hsaito Subscribers: dcaballe, hsaito, llvm-commits Differential Revision: https://reviews.llvm.org/D46191 llvm-svn: 331269
* Fix the issue that ComputeValueKnownInPredecessors only handles the case whenWei Mi2018-05-011-3/+15
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | phi is on lhs of a comparison op. For the following testcase, L1: %t0 = add i32 %m, 7 %t3 = icmp eq i32* %t2, null br i1 %t3, label %L3, label %L2 L2: %t4 = load i32, i32* %t2, align 4 br label %L3 L3: %t5 = phi i32 [ %t0, %L1 ], [ %t4, %L2 ] %t6 = icmp eq i32 %t0, %t5 br i1 %t6, label %L4, label %L5 We know if we go through the path L1 --> L3, %t6 should always be true. However currently, if the rhs of the eq comparison is phi, JumpThreading fails to evaluate %t6 to true. And we know that Instcombine cannot guarantee always canonicalizing phi to the left hand side of the comparison operation according to the operand priority comparison mechanism in instcombine. The patch handles the case when rhs of the comparison op is a phi. Differential Revision: https://reviews.llvm.org/D46275 llvm-svn: 331266
* [InstCombine] Adjusting bswap pattern matching to hold for And/Shift mixed caseOmer Paparo Bivas2018-05-011-1/+12
| | | | | | | Differential Revision: https://reviews.llvm.org/D45731 Change-Id: I85d4226504e954933c41598327c91b2d08192a9d llvm-svn: 331257
* [PM/LoopUnswitch] Remove the last manual domtree update code from loopChandler Carruth2018-05-011-170/+18
| | | | | | | | | unswitch and replace it with the amazingly simple update API code. This addresses piles of FIXMEs around the update logic here and makes everything substantially simpler. llvm-svn: 331247
* [PM/LoopUnswitch] Add back a successor set that was removed based onChandler Carruth2018-05-011-2/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | code review. It turns out this *is* necessary, and I read the comment on the API correctly the first time. ;] The `applyUpdates` routine requires that updates are "balanced". This is in order to cleanly handle cycles like inserting, removing, nad then re-inserting the same edge. This precludes inserting the same edge multiple times in a row as handling that would cause the insertion logic to become *ordered* instead of *unordered* (which is what the API provides). It happens that in this specific case nothing (other than an assert and contract violation) goes wrong because we're never inserting and removing the same edge. The implementation *happens* to do the right thing to eliminate redundant insertions in that case. But the requirement is there and there is an assert to catch it. Somehow, after the code review I never did another asserts-clang build testing loop-unswich for a long time. As a consequence, I didn't notice this despite a bunch of testing going on, but it shows up immediately with an asserts build of clang itself. llvm-svn: 331246
* [SimplifyCFG] Use BB::instructionsWithoutDebug to skip DbgInfo (NFC).Florian Hahn2018-04-301-37/+14
| | | | | | | | | | | | | | This patch updates some code responsible the skip debug info to use BasicBlock::instructionsWithoutDebug. I think this makes things slightly simpler and more direct. Reviewers: aprantl, vsk, hans, danielcdh Reviewed By: hans Differential Revision: https://reviews.llvm.org/D46252 llvm-svn: 331221
* [LoopSimplify] Use BB::instructionsWithoutDebug to skip DbgInfo (NFC).Florian Hahn2018-04-301-4/+1
| | | | | | | | | | | | | | This patch updates some code responsible the skip debug info to use BasicBlock::instructionsWithoutDebug. I think this makes things slightly simpler and more direct. Reviewers: aprantl, vsk, chandlerc Reviewed By: aprantl Differential Revision: https://reviews.llvm.org/D46253 llvm-svn: 331217
* [InstCombine] Unfold masked merge with constant maskRoman Lebedev2018-04-301-1/+15
| | | | | | | | | | | | | | | | | Summary: As discussed in D45733, we want to do this in InstCombine. https://rise4fun.com/Alive/LGk Reviewers: spatel, craig.topper Reviewed By: spatel Subscribers: chandlerc, xbolva00, llvm-commits Differential Revision: https://reviews.llvm.org/D45867 llvm-svn: 331205
* [SLPVectorizer] Debug info shouldn't impact spill cost computation.Davide Italiano2018-04-301-1/+4
| | | | | | | | | | <rdar://problem/39794738> (Also, PR32761). Differential Revision: https://reviews.llvm.org/D46199 llvm-svn: 331199
* IWYU for llvm-config.h in llvm, additions.Nico Weber2018-04-304-0/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | See r331124 for how I made a list of files missing the include. I then ran this Python script: for f in open('filelist.txt'): f = f.strip() fl = open(f).readlines() found = False for i in xrange(len(fl)): p = '#include "llvm/' if not fl[i].startswith(p): continue if fl[i][len(p):] > 'Config': fl.insert(i, '#include "llvm/Config/llvm-config.h"\n') found = True break if not found: print 'not found', f else: open(f, 'w').write(''.join(fl)) and then looked through everything with `svn diff | diffstat -l | xargs -n 1000 gvim -p` and tried to fix include ordering and whatnot. No intended behavior change. llvm-svn: 331184
* [LV] Use BB::instructionsWithoutDebug to skip DbgInfo (NFC).Florian Hahn2018-04-301-8/+3
| | | | | | | | | | | | | | This patch updates some code responsible the skip debug info to use BasicBlock::instructionsWithoutDebug. I think this makes things slightly simpler and more direct. Reviewers: mkuper, rengolin, dcaballe, aprantl, vsk Reviewed By: rengolin Differential Revision: https://reviews.llvm.org/D46254 llvm-svn: 331174
* [NFC][LV][LoopUtil] Move LoopVectorizationLegality to its own fileHideki Saito2018-04-293-1456/+1075
| | | | | | | | | | | | | | | | | | | | | Summary: This is a follow up to D45420 (included here since it is still under review and this change is dependent on that) and D45072 (committed). Actual change for this patch is LoopVectorize* and cmakefile. All others are all from D45420. LoopVectorizationLegality is an analysis and thus really belongs to Analysis tree. It is modular enough and it is reusable enough ---- we can further improve those aspects once uses outside of LV picks up. Hopefully, this will make it easier for people familiar with vectorization theory, but not necessarily LV itself to contribute, by lowering the volume of code they should deal with. We probably should start adding some code in LV to check its own capability (i.e., vectorization is legal but LV is not ready to handle it) and then bail out. Reviewers: rengolin, fhahn, hfinkel, mkuper, aemerson, mssimpso, dcaballe, sguggill Reviewed By: rengolin, dcaballe Subscribers: egarcia, rogfer01, mgorny, llvm-commits Differential Revision: https://reviews.llvm.org/D45552 llvm-svn: 331139
* [InstCombine] Canonicalize variable mask in masked mergeRoman Lebedev2018-04-281-0/+33
| | | | | | | | | | | | | | | | | | | Summary: Masked merge has a pattern of: `((x ^ y) & M) ^ y`. But, there is no difference between `((x ^ y) & M) ^ y` and `((x ^ y) & ~M) ^ x`, We should canonicalize the pattern to non-inverted mask. https://rise4fun.com/Alive/Yol Reviewers: spatel, craig.topper Reviewed By: spatel Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D45664 llvm-svn: 331112
* [LoopGuardWidening] Make PostDomTree optionalPhilip Reames2018-04-271-10/+28
| | | | | | | | The effect of doing so is not disrupting the LoopPassManager when mixing this pass with other loop passes. This should help locality of access substaintially and avoids the cost of computing PostDom. The assumption here is that the full GuardWidening (which does use PostDom) is run as a canonicalization before loop opts and that this version is just catching cases exposed by other loop passes. (i.e. LoopPredication, IndVarSimplify, LoopUnswitch, etc..) llvm-svn: 331094
* Fix a bug in GlobalOpt's handling of DIExpressions.Adrian Prantl2018-04-272-11/+7
| | | | | | | | | This patch adds support for fragment expressions TryToShrinkGlobalToBoolean() which were previously just dropped. Thanks to Reid Kleckner for providing me a reproducer! llvm-svn: 331086
* [PatternMatch] Stabilize the matching order of commutative matchersRoman Lebedev2018-04-272-31/+14
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: Currently, we 1. match `LHS` matcher to the `first` operand of binary operator, 2. and then match `RHS` matcher to the `second` operand of binary operator. If that does not match, we swap the `LHS` and `RHS` matchers: 1. match `RHS` matcher to the `first` operand of binary operator, 2. and then match `LHS` matcher to the `second` operand of binary operator. This works ok. But it complicates writing of commutative matchers, where one would like to match (`m_Value()`) the value on one side, and use (`m_Specific()`) it on the other side. This is additionally complicated by the fact that `m_Specific()` stores the `Value *`, not `Value **`, so it won't work at all out of the box. The last problem is trivially solved by adding a new `m_c_Specific()` that stores the `Value **`, not `Value *`. I'm choosing to add a new matcher, not change the existing one because i guess all the current users are ok with existing behavior, and this additional pointer indirection may have performance drawbacks. Also, i'm storing pointer, not reference, because for some mysterious-to-me reason it did not work with the reference. The first one appears trivial, too. Currently, we 1. match `LHS` matcher to the `first` operand of binary operator, 2. and then match `RHS` matcher to the `second` operand of binary operator. If that does not match, we swap the ~~`LHS` and `RHS` matchers~~ **operands**: 1. match ~~`RHS`~~ **`LHS`** matcher to the ~~`first`~~ **`second`** operand of binary operator, 2. and then match ~~`LHS`~~ **`RHS`** matcher to the ~~`second`~ **`first`** operand of binary operator. Surprisingly, `$ ninja check-llvm` still passes with this. But i expect the bots will disagree.. The motivational unittest is included. I'd like to use this in D45664. Reviewers: spatel, craig.topper, arsenm, RKSimon Reviewed By: craig.topper Subscribers: xbolva00, wdng, llvm-commits Differential Revision: https://reviews.llvm.org/D45828 llvm-svn: 331085
* [LICM] Reduce nesting with an early return [NFC]Philip Reames2018-04-271-48/+50
| | | | llvm-svn: 331080
* [LV] Common duplicate vector load/store address calculation (NFC)Daniel Neilson2018-04-271-32/+18
| | | | | | | | Summary: Commoning some obviously copy/paste code in InnerLoopVectorizer::vectorizeMemoryInstruction llvm-svn: 331076
* [GuardWidening] Add some clarifying comments about heuristics [NFC]Philip Reames2018-04-271-0/+8
| | | | llvm-svn: 331061
* [LoopGuardWidening] Split out a loop pass version of GuardWideningPhilip Reames2018-04-272-9/+75
| | | | | | | | The idea is to have a pass which performs the same transformation as GuardWidening, but can be run within a loop pass manager without disrupting the pass manager structure. As demonstrated by the test case, this doesn't quite get there because of issues with post dom, but it gives a good step in the right direction. the motivation is purely to reduce compile time since we can now preserve locality during the loop walk. This patch only includes a legacy pass. A follow up will add a new style pass as well. llvm-svn: 331060
* [LoopInterchange] Allow some loops with PHI nodes in the exit block.Florian Hahn2018-04-271-23/+48
| | | | | | | | | | | | | | | | | | | | We currently support LCSSA PHI nodes in the outer loop exit, if their incoming values do not come from the outer loop latch or if the outer loop latch has a single predecessor. In that case, the outer loop latch will be executed only if the inner loop gets executed. If we have multiple predecessors for the outer loop latch, it may be executed even if the inner loop does not get executed. This is a first step to support the case described in https://bugs.llvm.org/show_bug.cgi?id=30472 Reviewers: efriedma, karthikthecool, mcrosier Reviewed By: efriedma Differential Revision: https://reviews.llvm.org/D43237 llvm-svn: 331037
* Revert "[SimplifyLibcalls] Replace locked IO with unlocked IO"Matt Morehouse2018-04-272-216/+19
| | | | | | This reverts r331002 due to sanitizer bot breakage. llvm-svn: 331011
* [LowerTypeTests] Mark .cfi.jumptable nounwind.Eli Friedman2018-04-271-0/+2
| | | | | | | | | It doesn't unwind, and the wrong marking leads to the creation of an .eh_frame section when it isn't necessary. Differential Revision: https://reviews.llvm.org/D46082 llvm-svn: 331008
* [SimplifyLibcalls] Replace locked IO with unlocked IODavid Bolvansky2018-04-262-19/+216
| | | | | | | | | | | | Summary: If file stream arg is not captured and source is fopen, we could replace IO calls by unlocked IO ("_unlocked" function variants) to gain better speed, Reviewers: efriedma, RKSimon, spatel, sanjoy, hfinkel, majnemer Subscribers: lebedev.ri, llvm-commits Differential Revision: https://reviews.llvm.org/D45736 llvm-svn: 331002
* [InstCombine] Simplify Add with remainder expressions as operands.Sanjoy Das2018-04-262-0/+116
| | | | | | | | | | | | | | | | | | | | | Summary: Simplify integer add expression X % C0 + (( X / C0 ) % C1) * C0 to X % (C0 * C1). This is a common pattern seen in code generated by the XLA GPU backend. Add test cases for this new optimization. Patch by Bixia Zheng! Reviewers: sanjoy Reviewed By: sanjoy Subscribers: efriedma, craig.topper, lebedev.ri, llvm-commits, jlebar Differential Revision: https://reviews.llvm.org/D45976 llvm-svn: 330992
* Revert "Enable EliminateAvailableExternally pass for -O1"Vlad Tsyrklevich2018-04-261-1/+1
| | | | | | This reverts commit r330961 because it breaks a handful of clang tests. llvm-svn: 330964
* Enable EliminateAvailableExternally pass for -O1Vlad Tsyrklevich2018-04-261-1/+1
| | | | | | | | | | | | | | | | | | Summary: Follow-up to D43690, the EliminateAvailableExternally pass currently runs under -O0 and -O2 and up. Under -O1 we would still want to drop available_externally symbols to reduce space without inlining having run. Reviewers: tejohnson Reviewed By: tejohnson Subscribers: mehdi_amini, llvm-commits, kcc Differential Revision: https://reviews.llvm.org/D46093 llvm-svn: 330961
OpenPOWER on IntegriCloud