summaryrefslogtreecommitdiffstats
path: root/llvm/lib/Transforms
Commit message (Collapse)AuthorAgeFilesLines
* [InstCombine] Change LLVM To canonicalize toward the value type beingChandler Carruth2014-11-251-100/+72
| | | | | | | | | | | | | | | | | | | | | | | | | | stored rather than the pointer type. This change is analogous to r220138 which changed the canonicalization for loads. The rationale is the same: memory does not have a type, operations (and thus the values they produce) have a type. We should match that type as closely as possible rather than reading some form of semantics into the pointer type. With this change, loads and stores should no longer be made with nonsensical types for the values that tehy load and store. This is particularly important when trying to match specific loaded and stored types in the process of doing other instcombines, which is what led me down this twisty maze of miscanonicalization. I've put quite some effort into looking through IR to find places where LLVM's optimizer was being unreasonably conservative in the face of mismatched load and store types, however it is possible (let's say, likely!) I have missed some. If you see regressions here, or from r220138, the likely cause is some part of LLVM failing to cope with load and store types differing. Test cases appreciated, it is important that we root all of these out of LLVM. llvm-svn: 222748
* Revert r220349 to re-instate r220277 with a fix for PR21330 -- quiteChandler Carruth2014-11-252-5/+6
| | | | | | | | | | | | | | | | | | | | | | | | | clearly only exactly equal width ptrtoint and inttoptr casts are no-op casts, it says so right there in the langref. Make the code agree. Original log from r220277: Teach the load analysis to allow finding available values which require inttoptr or ptrtoint cast provided there is datalayout available. Eventually, the datalayout can just be required but in practice it will always be there today. To go with the ability to expose available values requiring a ptrtoint or inttoptr cast, helpers are added to perform one of these three casts. These smarts are necessary to finish canonicalizing loads and stores to the operational type requirements without regressing fundamental combines. I've added some test cases. These should actually improve as the load combining and store combining improves, but they may fundamentally be highlighting some missing combines for select in addition to exercising the specific added logic to load analysis. llvm-svn: 222739
* Bug 21610: Canonicalize min/max fcmp selects to use ordered comparisonsMatt Arsenault2014-11-241-1/+30
| | | | llvm-svn: 222705
* [asan/coverage] change the way asan coverage instrumentation is done: ↵Kostya Serebryany2014-11-241-10/+7
| | | | | | instead of setting the guard to 1 in the generated code, pass the pointer to guard to __sanitizer_cov and set it there. No user-visible functionality change expected llvm-svn: 222675
* InstCombine: Don't create an unused instructionDavid Majnemer2014-11-241-2/+1
| | | | | | | | | | We would create an instruction but not inserting it. Not inserting the unused instruction would lead us to verification failure. This fixes PR21653. llvm-svn: 222659
* InstCombine: Don't assume DataLayout is always availableDavid Majnemer2014-11-241-1/+2
| | | | | | | | | We tried to get the result of DataLayout::getLargestLegalIntTypeSize but we didn't have a DataLayout. This resulted in opt crashing. This fixes PR21651. llvm-svn: 222645
* Masked Vector Load and Store Intrinsics.Elena Demikhovsky2014-11-231-15/+83
| | | | | | | | | | | | | | Introduced new target-independent intrinsics in order to support masked vector loads and stores. The loop vectorizer optimizes loops containing conditional memory accesses by generating these intrinsics for existing targets AVX2 and AVX-512. The vectorizer asks the target about availability of masked vector loads and stores. Added SDNodes for masked operations and lowering patterns for X86 code generator. Examples: <16 x i32> @llvm.masked.load.v16i32(i8* %addr, <16 x i32> %passthru, i32 4 /* align */, <16 x i1> %mask) declare void @llvm.masked.store.v8f64(i8* %addr, <8 x double> %value, i32 4, <8 x i1> %mask) Scalarizer for other targets (not AVX2/AVX-512) will be done in a separate patch. http://reviews.llvm.org/D6191 llvm-svn: 222632
* InstCombine: Propagate exact for (sdiv X, Pow2) -> (udiv X, Pow2)David Majnemer2014-11-221-2/+4
| | | | llvm-svn: 222625
* InstCombine: Propagate exact for (sdiv X, Y) -> (udiv X, Y)David Majnemer2014-11-221-1/+3
| | | | llvm-svn: 222624
* InstCombine: Propagate exact for (sdiv -X, C) -> (sdiv X, -C)David Majnemer2014-11-221-4/+6
| | | | llvm-svn: 222623
* Tidied up target triple OS detection. NFCSimon Pilgrim2014-11-221-2/+2
| | | | | | Use Triple::isOS*() helper functions where possible. llvm-svn: 222622
* InstCombine: Propagate exact in (udiv (lshr X,C1),C2) -> (udiv x,C1<<C2)David Majnemer2014-11-221-2/+7
| | | | llvm-svn: 222620
* InstCombine: Propagate NSW/NUW for X*(1<<Y) -> X<<YDavid Majnemer2014-11-221-4/+17
| | | | llvm-svn: 222613
* InstCombine: Propagate NSW for -X * -Y -> X * YDavid Majnemer2014-11-221-3/+10
| | | | llvm-svn: 222612
* InstCombine: Silence a parenthesis warningDavid Majnemer2014-11-221-1/+1
| | | | llvm-svn: 222609
* InstCombine: Preserve nsw when folding X*(2^C) -> X << CDavid Majnemer2014-11-221-0/+2
| | | | llvm-svn: 222606
* InstCombine: Preserve nsw/nuw for ((X << C2)*C1) -> (X * (C1 << C2))David Majnemer2014-11-221-3/+12
| | | | llvm-svn: 222605
* InstCombine: Preserve nsw for (mul %V, -1) -> (sub 0, %V)David Majnemer2014-11-221-2/+7
| | | | llvm-svn: 222604
* [InstCombine] Re-commit of r218721 (Optimize icmp-select-icmp sequence)Gerolf Hoflehner2014-11-213-10/+168
| | | | | | | Fixes the self-host fail. Note that this commit activates dominator analysis in the combiner by default (like the original commit did). llvm-svn: 222590
* [asan] remove old experimental codeKostya Serebryany2014-11-211-38/+0
| | | | llvm-svn: 222586
* [asan] add statistic counter to dynamic alloca instrumentationKostya Serebryany2014-11-211-0/+3
| | | | llvm-svn: 222573
* Disable header duplication at -Oz in loop-rotate pass.Roman Divacky2014-11-211-1/+2
| | | | llvm-svn: 222562
* [asan] Add new hidden compile-time flag asan-instrument-allocas to sanitize ↵Yury Gribov2014-11-211-6/+227
| | | | | | | | variable-sized dynamic allocas. Patch by Max Ostapenko. Reviewed at http://reviews.llvm.org/D6055 llvm-svn: 222519
* This Reassociate change unintentionally slipped in r222499David Majnemer2014-11-211-7/+0
| | | | llvm-svn: 222500
* SROA: The alloca type isn't a candidate promotion type for vectorsDavid Majnemer2014-11-212-3/+9
| | | | | | | | | | | | The alloca's type is irrelevant, only those types which are used in a load or store of the exact size of the slice should be considered. This manifested as an assertion failure when we compared the various types: we had a size mismatch. This fixes PR21480. llvm-svn: 222499
* SimplifyCFG: Refactor GatherConstantCompares() result in a structMehdi Amini2014-11-201-133/+152
| | | | | | | | | | Code seems cleaner and easier to understand this way This is basically r222416, after fixes for MSVC lack of standard support, and a few cleaning (got rid of a warning). Thanks Nakamura Takumi and Nico Weber for the MSVC fixes. llvm-svn: 222472
* Fix a trip-count overflow issue in LoopUnroll.Michael Zolotukhin2014-11-201-2/+11
| | | | | | | | | | | | Currently LoopUnroll generates a prologue loop before the main loop body to execute first N%UnrollFactor iterations. Also, this loop is used if trip-count can overflow - it's determined by a runtime check. However, we've been mistakenly optimizing this loop to a linear code for UnrollFactor = 2, not taking into account that it also serves as a safe version of the loop if its trip-count overflows. llvm-svn: 222451
* Revert r222416, r222422, r222426: the former revision had problems and ↵Timur Iskhodzhanov2014-11-201-150/+136
| | | | | | fixing them introduced bugs llvm-svn: 222428
* Fix a typoTimur Iskhodzhanov2014-11-201-1/+1
| | | | llvm-svn: 222426
* SimplifyCFG.cpp: Tweak to let msc17 compliant.NAKAMURA Takumi2014-11-201-8/+11
| | | | | | | | - Use LLVM_DELETED_FUNCTION. - Don't use member initializers. - Don't use initializer list. llvm-svn: 222422
* SimplifyCFG: Refactor GatherConstantCompares() result in a structMehdi Amini2014-11-201-136/+147
| | | | | | Code seems cleaner and easier to understand this way llvm-svn: 222416
* Revert "[Reassociate] As the expression tree is rewritten make sure the ↵Chad Rosier2014-11-191-8/+7
| | | | | | | | | | | | | operands are" This reverts commit r222142. This is causing/exposing an execution-time regression in spec2006/gcc and coremark on AArch64/A57/Ofast. Conflicts: test/Transforms/Reassociate/optional-flags.ll llvm-svn: 222398
* Try to fix MSVS build after r222384. No intended behavior change.Nico Weber2014-11-191-3/+3
| | | | llvm-svn: 222386
* SimplifyCFG: turn recursive GatherConstantCompares into iterativeMehdi Amini2014-11-191-99/+138
| | | | | | A long sequence of || or && could lead to a stack explosion. llvm-svn: 222384
* Vectorize a reduction chain feeding into a 'return' statement.Suyog Sarda2014-11-191-0/+15
| | | | | | | | | e.x return (a[0]+b[0]) + (a[1]+b[1]) Differential Revision: http://reviews.llvm.org/D6227 llvm-svn: 222364
* Fix tail recursion eliminationArnaud A. de Grandmaison2014-11-191-3/+25
| | | | | | | | | | | | | | | | | | | | | | When the BasicBlock containing the return instrution has a PHI with 2 incoming values, FoldReturnIntoUncondBranch will remove the no longer used incoming value and remove the no longer needed phi as well. This leaves us with a BB that no longer has a PHI, but the subsequent call to FoldReturnIntoUncondBranch from FoldReturnAndProcessPred will not remove the return instruction (which still uses the result of the call instruction). This prevents EliminateRecursiveTailCall to remove the value, as it is still being used in a basicblock which has no predecessors. The basicblock can not be erased on the spot, because its iterator is still being used in runTRE. This issue was exposed when removing the threshold on size for lifetime marker insertion for named temporaries in clang. The testcase is a much reduced version of peelOffOuterExpr(const Expr*, const ExplodedNode *) from clang/lib/StaticAnalyzer/Core/BugReporterVisitors.cpp. llvm-svn: 222354
* Update SetVector to rely on the underlying set's insert to return a ↵David Blaikie2014-11-1931-81/+87
| | | | | | | | | | | | | pair<iterator, bool> This is to be consistent with StringSet and ultimately with the standard library's associative container insert function. This lead to updating SmallSet::insert to return pair<iterator, bool>, and then to update SmallPtrSet::insert to return pair<iterator, bool>, and then to update all the existing users of those functions... llvm-svn: 222334
* [SeparateConstOffsetFromGEP] Allow SeparateConstOffsetFromGEP pass to lower ↵Hao Liu2014-11-191-40/+272
| | | | | | | | | | | | GEPs. If LowerGEP is enabled, it can lower a GEP with multiple indices into GEPs with a single index or arithmetic operations. Lowering GEPs can always extract structure indices. Lowering GEPs can also give use more optimization opportunities. It can benefit passes like CSE, LICM and CGP. Reviewed in http://reviews.llvm.org/D5864 llvm-svn: 222328
* [asan] add experimental basic-block tracing to asan-coverage; also fix ↵Kostya Serebryany2014-11-192-7/+43
| | | | | | -fsanitize-coverage=3 which was broken by r221718 llvm-svn: 222290
* Introduce llvm::SplitAllCriticalEdgesKostya Serebryany2014-11-192-19/+17
| | | | | | | | | | | | | | | | | | | | Summary: move the code from BreakCriticalEdges::runOnFunction() into a separate utility function llvm::SplitAllCriticalEdges() so that it can be used independently. No functionality change intended. Test Plan: check-llvm Reviewers: nlewycky Reviewed By: nlewycky Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D6313 llvm-svn: 222288
* Revert r222039 because of bot failure.Manman Ren2014-11-191-175/+161
| | | | | | | http://lab.llvm.org:8080/green/job/clang-Rlto_master/298/ Hopefully, bot will be green. If not, we will re-submit the commit. llvm-svn: 222287
* InstCombine: Fix another infinite loop caused by visitFPTruncDavid Majnemer2014-11-181-5/+4
| | | | | | | | | | We would attempt to replace an frem's operand with the same operand. This would cause InstCombine to think real work was done, causing InstCombine to enter an infinite loop. This fixes the second part of PR21576. llvm-svn: 222265
* Revert "Revert r222040 because of bot failure."David Majnemer2014-11-181-6/+9
| | | | | | | This reverts commit r222203, reverting r222040 didn't end up turning the bot green. llvm-svn: 222261
* [Reassociate] Rename local variable to not use same name as a memberChad Rosier2014-11-181-4/+4
| | | | | | variable. NFC. llvm-svn: 222248
* Tweak EarlyCSE to recognize series of dead storesPhilip Reames2014-11-181-1/+1
| | | | | | | | | EarlyCSE is giving up on the current instruction immediately when it recognizes that the current instruction makes a previous store trivially dead. There's no reason to do this. Once the previous store has been deleted, it's perfectly legal to remember the value of the current store (for value forwarding) and the fact the store occurred (it could be dead too!). Reviewed by: Hal Differential Revision: http://reviews.llvm.org/D6301 llvm-svn: 222241
* InstCombine: Fold away tautological masked comparesDavid Majnemer2014-11-181-1/+1
| | | | | | | | | It is impossible for (x & INT_MAX) == 0 && x == INT_MAX to ever be true. While this sort of reasoning should normally live in InstSimplify, the machinery that derives this result is not trivial to split out. llvm-svn: 222230
* InstCombine: Clean up foldLogOpOfMaskedICmpsDavid Majnemer2014-11-181-16/+14
| | | | | | No functional change intended. llvm-svn: 222229
* SimplifyCFG: Range'ify some for-loops. No functional change.Hans Wennborg2014-11-181-12/+13
| | | | llvm-svn: 222215
* IndVarSimplify: Allow LFTR to fire more oftenDavid Majnemer2014-11-181-1/+22
| | | | | | | | | | | | | I added a pessimization in r217102 to prevent miscompiles when the incremented induction variable was used in a comparison; it would be poison. Try to use the incremented induction variable more often when we can be sure that the increment won't end in poison. Differential Revision: http://reviews.llvm.org/D6222 llvm-svn: 222213
* Revert r222040 because of bot failure.Manman Ren2014-11-181-9/+6
| | | | | | | http://lab.llvm.org:8080/green/job/clang-Rlto_master/298/ Hopefully, bot will be green. llvm-svn: 222203
OpenPOWER on IntegriCloud