summaryrefslogtreecommitdiffstats
path: root/llvm/lib/Transforms
Commit message (Collapse)AuthorAgeFilesLines
...
* Fix "field 'DFS' will be initialized after field 'DTU'" warning. NFCI.Simon Pilgrim2019-02-151-1/+1
| | | | llvm-svn: 354123
* [NFC] Promote DFS to field for further useMax Kazantsev2019-02-151-2/+2
| | | | llvm-svn: 354118
* [NFC] Tweak SplitBlockAndInsertIfThen to use existing ThenBlockMax Kazantsev2019-02-151-8/+16
| | | | llvm-svn: 354107
* [ThinLTO] Detect partially split modules during the thin linkTeresa Johnson2019-02-142-18/+16
| | | | | | | | | | | | | | | | | | | | | | | | Summary: The changes to disable LTO unit splitting by default (r350949) and detect inconsistently split LTO units (r350948) are causing some crashes when the inconsistency is detected in multiple threads simultaneously. Fix that by having the code always look for the inconsistently split LTO units during the thin link, by checking for the presence of type tests recorded in the summaries. Modify test added in r350948 to remove single threading required to fix a bot failure due to this issue (and some debugging options added in the process of diagnosing it). Reviewers: pcc Subscribers: mehdi_amini, inglorion, eraman, steven_wu, dexonsmith, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D57561 llvm-svn: 354062
* [InstCombine] Add todos for possible atomicrmw transformsPhilip Reames2019-02-141-0/+6
| | | | llvm-svn: 354059
* Canonicalize all integer "idempotent" atomicrmw opsPhilip Reames2019-02-141-5/+13
| | | | | | | | | | For "idempotent" atomicrmw instructions which we can't simply turn into load, canonicalize the operation and constant. This reduces the matching needed elsewhere in the optimizer, but doesn't directly impact codegen. For any architecture where OR/Zero is not a good default choice, you can extend the AtomicExpand lowerIdempotentRMWIntoFencedLoad mechanism. I reviewed X86 to make sure this works well, haven't audited other backends. Differential Revision: https://reviews.llvm.org/D58244 llvm-svn: 354058
* Teach instcombine about remaining "idempotent" atomicrmw typesPhilip Reames2019-02-141-30/+60
| | | | | | | | | | Expand on Quentin's r353471 patch which converts some atomicrmws into loads. Handle remaining operation types, and fix a slight bug. Atomic loads are required to have alignment. Since this was within the InstCombine fixed point, somewhere else in InstCombine was adding alignment before the verifier saw it, but still, we should fix. Terminology wise, I'm using the "idempotent" naming that is used for the same operations in AtomicExpand and X86ISelLoweringInfo. Once this lands, I'll add similar tests for AtomicExpand, and move the pattern match function to a common location. In the review, there was seemingly consensus that "idempotent" was slightly incorrect for this context. Once we setle on a better name, I'll update all uses at once. Differential Revision: https://reviews.llvm.org/D58242 llvm-svn: 354046
* Refine ArgPromotion metadata handlingTeresa Johnson2019-02-141-0/+2
| | | | | | | | | | | | | | | | | | | | Summary: In r353537 we now copy all metadata to the new function, with the old being removed when the old function is eliminated. In some cases the old function is dropped to a declaration (seems to only occur with the old PM). Go ahead and clear all metadata from the old function to handle that case, since verification will complain otherwise. This is consistent with what was being done for debug metadata before r353537. Reviewers: davidxl, uabelho Subscribers: jdoerfert, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D58215 llvm-svn: 354032
* [LoopUnrollPeel] Add case where we should forget the peeled loop from SCEV.Florian Hahn2019-02-141-10/+8
| | | | | | | | | | | | | | | | | | | | The test case requires the peeled loop to be forgotten after peeling, even though it does not have a parent. When called via the unroller, SE->forgetTopmostLoop is also called, so the test case would also pass without any SCEV invalidation, but peelLoop is exposed as utility function. Also, in the test case, simplifyLoop will make changes, removing the loop from SCEV, but it is better to not rely on this behavior. Reviewers: sanjoy, mkazantsev Reviewed By: mkazantsev Tags: #llvm Differential Revision: https://reviews.llvm.org/D58192 llvm-svn: 354031
* [Instrumentation][NFC] Fix warning.Clement Courbet2019-02-141-1/+1
| | | | | | lib/Transforms/Instrumentation/AddressSanitizer.cpp:1173:29: warning: extra ‘;’ [-Wpedantic] llvm-svn: 354024
* [NFC] Refactor LICM code for better readabilityMax Kazantsev2019-02-141-6/+11
| | | | llvm-svn: 354013
* [NewPM] Second attempt at porting ASanLeonard Chan2019-02-132-184/+261
| | | | | | | | | | | | | | | | | | | | This is the second attempt to port ASan to new PM after D52739. This takes the initialization requried by ASan from the Module by moving it into a separate class with it's own analysis that the new PM ASan can use. Changes: - Split AddressSanitizer into 2 passes: 1 for the instrumentation on the function, and 1 for the pass itself which creates an instance of the first during it's run. The same is done for AddressSanitizerModule. - Add new PM AddressSanitizer and AddressSanitizerModule. - Add legacy and new PM analyses for reading data needed to initialize ASan with. - Removed DominatorTree dependency from ASan since it was unused. - Move GlobalsMetadata and ShadowMapping out of anonymous namespace since the new PM analysis holds these 2 classes and will need to expose them. Differential Revision: https://reviews.llvm.org/D56470 llvm-svn: 353985
* [CodeExtractor] Only lift lifetime markers present in the extraction regionVedant Kumar2019-02-131-37/+59
| | | | | | | | | | | | | | | When CodeExtractor finds liftime markers referencing inputs to the extraction region, it lifts these markers out of the region and inserts them around the call to the extracted function (see r350420, PR39671). However, it should *only* lift lifetime markers that are actually present in the extraction region. I.e., if a start marker is present in the extraction region but a corresponding end marker isn't (or vice versa), only the start marker (or end marker, resp.) should be lifted. Differential Revision: https://reviews.llvm.org/D57834 llvm-svn: 353973
* [NFC] Add const qualifiers where possibleMax Kazantsev2019-02-131-28/+29
| | | | llvm-svn: 353941
* [DebugInfo][InstCombine] Prefer to salvage debuginfo over sinking itJeremy Morse2019-02-131-5/+27
| | | | | | | | | | | | | | | | | | When instcombine sinks an instruction between two basic blocks, it sinks any dbg.value users in the source block with it, to prevent debug use-before-free. However we can do better by attempting to salvage the debug users, which would avoid moving where the variable location changes. If we successfully salvage, still sink a (cloned) dbg.value with the sunk instruction, as the sunk instruction is more likely to be "live" later in the compilation process. If we can't salvage dbg.value users of a sunk instruction, mark the dbg.values in the original block as being undef. This terminates any earlier variable location range, and represents the fact that we've optimized out the variable location for a portion of the program. Differential Revision: https://reviews.llvm.org/D56788 llvm-svn: 353936
* [GuardWidening] Support widening of explicitly expressed guardsMax Kazantsev2019-02-131-3/+30
| | | | | | | | | | This patch adds support of guards expressed in explicit form via `widenable_condition` in Guard Widening pass. Differential Revision: https://reviews.llvm.org/D56075 Reviewed By: reames llvm-svn: 353932
* [LoopSimplifyCFG] Re-enable const branch folding by defaultMax Kazantsev2019-02-131-1/+1
| | | | | | | | Known underlying bugs have been fixed, intensive fuzz testing did not find any new problems. Re-enabling by default. Feel free to revert if it causes any functional failures. llvm-svn: 353911
* [MemorySSA & LoopPassManager] Add remaining book keeping [NFCI].Alina Sbirlea2019-02-122-3/+10
| | | | | | | | Add plumbing to get MemorySSA in the remaining loop passes. Also update unit test to add the dependency. [EnableMSSALoopDependency remains disabled]. llvm-svn: 353901
* [LICM] Cap the clobbering calls in LICM.Alina Sbirlea2019-02-121-25/+38
| | | | | | | | | | | | | | | | | | | Summary: Unlimitted number of calls to getClobberingAccess can lead to high compile times in pathological cases. Switching EnableLicmCap flag from bool to int, and enabling to default 100. (tested to be appropriate for current bechmarks) We can revisit this value when enabling MemorySSA. Reviewers: sanjoy, chandlerc, george.burgess.iv Subscribers: jlebar, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D57968 llvm-svn: 353897
* [DebugInfo] Don't salvage load operations (PR40628).Jeremy Morse2019-02-121-3/+3
| | | | | | | | | | | | | | | | | | | | | | | | Salvaging a redundant load instruction into a debug expression hides a memory read from optimisation passes. Passes that alter memory behaviour (such as LICM promoting memory to a register) aren't aware of these debug memory reads and leave them unaltered, making the debug variable location point somewhere unsafe. Teaching passes to know about these debug memory reads would be challenging and probably incomplete. Finding dbg.value instructions that need to be fixed would likely be computationally expensive too, as more analysis would be required. It's better to not generate debug-memory-reads instead, alas. Changed tests: * DeadStoreElim: test for salvaging of intermediate operations contributing to the dead store, instead of salvaging of the redundant load, * GVN: remove debuginfo behaviour checks completely, this behaviour is still covered by other tests, * InstCombine: don't test for salvaged loads, we're removing that behaviour. Differential Revision: https://reviews.llvm.org/D57962 llvm-svn: 353824
* [IndVars] Fix corner case with unreachable Phi inputs. PR40454Max Kazantsev2019-02-121-6/+20
| | | | | | | | | | | | | | | Logic in `getInsertPointForUses` doesn't account for a corner case when `Def` only comes to a Phi user from unreachable blocks. In this case, the incoming value may be arbitrary (and not even available in the input block) and break the loop-related invariants that are asserted below. In fact, if we encounter this situation, no IR modification is needed. This Phi will be simplified away with nearest cleanup. Differential Revision: https://reviews.llvm.org/D58045 Reviewed By: spatel llvm-svn: 353816
* [LoopSimplifyCFG] Change logic of dead loops removal to avoid hitting assertsMax Kazantsev2019-02-121-4/+21
| | | | | | | | | | | | | | | | | | | | The function `LI.erase` has some invariants that need to be preserved when it tries to remove a loop which is not the top-level loop. In particular, it requires loop's preheader to be strictly in loop's parent. Our current logic of deletion of dead blocks may erase the information about preheader before we handle the loop, and therefore we may hit this assertion. This patch changes the logic of loop deletion: we make them top-level loops before we actually erase them. This allows us to trigger the simple branch of `erase` logic which just detatches blocks from the loop and does not try to do some complex stuff that need this invariant. Thanks to @uabelho for reporting this! Differential Revision: https://reviews.llvm.org/D57221 Reviewed By: fedor.sergeev llvm-svn: 353813
* Delete blocks from DTU to avoid dangling pointersMax Kazantsev2019-02-121-1/+1
| | | | llvm-svn: 353804
* [LoopSimplifyCFG] Pay respect to LCSSA when removing dead blocksMax Kazantsev2019-02-121-1/+1
| | | | | | | | | | | Utility function that we use for blocks deletion always unconditionally removes one-input Phis. In LoopSimplifyCFG, it can lead to breach of LCSSA form. This patch alters this function to keep them if needed. Differential Revision: https://reviews.llvm.org/D57231 Reviewed By: fedor.sergeev llvm-svn: 353803
* [NFC] Rename DontDeleteUselessPHIs --> KeepOneInputPHIsMax Kazantsev2019-02-126-16/+16
| | | | llvm-svn: 353801
* [NFC] Add parameter for keeping one-input Phis in DeleteDeadBlock(s)Max Kazantsev2019-02-121-7/+9
| | | | llvm-svn: 353799
* [LoopReroll] Fix reroll root legality checking.Eli Friedman2019-02-121-0/+10
| | | | | | | | | | | The code checked that the first root was an appropriate distance from the base value, but skipped checking the other roots. This could lead to rerolling a loop that can't be legally rerolled (at least, not without rewriting the loop in a non-trivial way). Differential Revision: https://reviews.llvm.org/D56812 llvm-svn: 353779
* Refactor setAlreadyUnrolled() and setAlreadyVectorized().Michael Kruse2019-02-111-51/+19
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Loop::setAlreadyUnrolled() and LoopVectorizeHints::setLoopAlreadyUnrolled() both add loop metadata that stops the same loop from being transformed multiple times. This patch merges both implementations. In doing so we fix 3 potential issues: * setLoopAlreadyUnrolled() kept the llvm.loop.vectorize/interleave.* metadata even though it will not be used anymore. This already caused problems such as http://llvm.org/PR40546. Change the behavior to the one of setAlreadyUnrolled which deletes this loop metadata. * setAlreadyUnrolled() used to create a new LoopID by calling MDNode::get with nullptr as the first operand, then replacing it by the returned references using replaceOperandWith. It is possible that MDNode::get would instead return an existing node (due to de-duplication) that then gets modified. To avoid, use a fresh TempMDNode that does not get uniqued with anything else before replacing it with replaceOperandWith. * LoopVectorizeHints::matchesHintMetadataName() only compares the suffix of the attribute to set the new value for. That is, when called with "enable", would erase attributes such as "llvm.loop.unroll.enable", "llvm.loop.vectorize.enable" and "llvm.loop.distribute.enable" instead of the one to replace. Fortunately, function was only called with "isvectorized". Differential Revision: https://reviews.llvm.org/D57566 llvm-svn: 353738
* [InstCombine] Fix matchRotate bug when one operand is a ConstantExpr shiftSanjay Patel2019-02-111-3/+7
| | | | | | | | | | | | | | | | | | This bug seems to be harmless in release builds, but will cause an error in UBSAN builds or an assertion failure in debug builds. When it gets to this opcode comparison, it assumes both of the operands are BinaryOperators, but the prior m_LogicalShift will also match a ConstantExpr. The cast<BinaryOperator> will assert in a debug build, or reading an invalid value for BinaryOp from memory with ((BinaryOperator*)constantExpr)->getOpcode() will cause an error in a UBSAN build. The test I added will fail without this change in debug/UBSAN builds, but not in release. Patch by: @AndrewScheidecker (Andrew Scheidecker) Differential Revision: https://reviews.llvm.org/D58049 llvm-svn: 353736
* [LICM&MSSA] Limit store hoisting.Alina Sbirlea2019-02-112-14/+39
| | | | | | | | | | | | | | | | | | | Summary: If there is no clobbering access for a store inside the loop, that store can only be hoisted if there are no interfearing loads. A more general verification introduced here: there are no loads that are not optimized to an access outside the loop. Addresses PR40586. Reviewers: george.burgess.iv Subscribers: sanjoy, jlebar, Prazek, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D57967 llvm-svn: 353734
* Update more files added with the old header to the new one.Chandler Carruth2019-02-111-4/+3
| | | | llvm-svn: 353667
* Update files that were mistakenly added with the old file header to theChandler Carruth2019-02-112-8/+6
| | | | | | new one. llvm-svn: 353665
* [CallSite removal] Migrate ConstantFolding APIs and implementation toChandler Carruth2019-02-113-5/+7
| | | | | | | | | `CallBase`. Users have been updated. You can see how to update any out-of-tree usages: pass `cast<CallBase>(CS.getInstruction())`. llvm-svn: 353661
* [CallSite removal] Migrate the statepoint GC infrastructure to use theChandler Carruth2019-02-113-121/+109
| | | | | | | | | | | | | | | `CallBase` class rather than `CallSite` wrappers. I pushed this change down through most of the statepoint infrastructure, completely removing the use of CallSite where I could reasonably do so. I ended up making a couple of cut-points: generic call handling (instcombine, TLI, SDAG). As soon as it hit truly generic handling with users outside the immediate code, I simply transitioned into or out of a `CallSite` to make this a reasonable sized chunk. Differential Revision: https://reviews.llvm.org/D56122 llvm-svn: 353660
* [Local] Delete a redundant check. NFCFangrui Song2019-02-101-1/+1
| | | | | | isInstructionTriviallyDead also performs the use_empty() check. llvm-svn: 353637
* [InstCombine] Fix an unused variable warning.Craig Topper2019-02-101-1/+1
| | | | llvm-svn: 353630
* [GlobalOpt] Simplify __cxa_atexit eliminationFangrui Song2019-02-091-39/+9
| | | | | | | | | | | | | cxxDtorIsEmpty checks callers recursively to determine if the __cxa_atexit-registered function is empty, and eliminates the __cxa_atexit call accordingly. This recursive check is unnecessary as redundant instructions and function calls can be removed by early-cse and inliner. In addition, cxxDtorIsEmpty does not mark visited function and it may visit a function exponential times (multiplication principle). llvm-svn: 353603
* Extra processing for BitCast + PHI in InstCombineGabor Buella2019-02-091-11/+34
| | | | | | | | | | | | | | | | | | | | | | | For some specific cases with bitcast A->B->A with intervening PHI nodes InstCombiner::optimizeBitCastFromPhi transformation creates extra PHI nodes, which are actually a copy of already created PHI or in another words, they are redundant. These extra PHI nodes could lead to extra move instructions generated after DeSSA transformation. This happens when several conditions are met - SROA kicks in and creates new alloca; - there is a simple assignment L = R, which falls under 'canonicalize loads' done by combineLoadToOperationType (this transformation is by default). Exactly this transformation is the reason of bitcasts generated; - the alloca is then used in A->B->A + PHI chain; - there is a loop unrolling. As a result optimizeBitCastFromPhi creates as many of PHI nodes for each new SROA alloca as loop unrolling factor is. These new extra PHI nodes are redundant actually except of one and should not be created. Moreover the idea of optimizeBitCastFromPhi is to get rid of the cast (when possible) but that doesn't happen in these conditions. The proposed fix is to do the cast replacement for the whole calculated/accumulated PHI closure not for one cast only, which is an argument to the optimizeBitCastFromPhi. These will help to accomplish several things: 1) avoid extra PHI nodes generated as all casts which may trigger optimizeBitCastFromPhi transformation will be replaced, 3) bitcasts will be replaced, and 3) create more opportunities to remove dead code, which appears after the replacement. A new test case shows that it's possible to get rid of all bitcasts completely and get quite good code reduction. Author: Igor Tsimbalist <igor.v.tsimbalist@intel.com> Reviewed By: Carrot Differential Revision: https://reviews.llvm.org/D57053 llvm-svn: 353595
* [NFC] Avoid passing blocks vector to the OutlineRegionInfo constructor by value.Sergey Dmitriev2019-02-081-4/+3
| | | | | | | | | | | | | | Reviewers: vsk, fhahn, davidxl Reviewed By: vsk Subscribers: hiraditya, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D57957 llvm-svn: 353582
* Implementation of asm-goto support in LLVMCraig Topper2019-02-0813-35/+126
| | | | | | | | | | | | | | | | | | | | | | | | | This patch accompanies the RFC posted here: http://lists.llvm.org/pipermail/llvm-dev/2018-October/127239.html This patch adds a new CallBr IR instruction to support asm-goto inline assembly like gcc as used by the linux kernel. This instruction is both a call instruction and a terminator instruction with multiple successors. Only inline assembly usage is supported today. This also adds a new INLINEASM_BR opcode to SelectionDAG and MachineIR to represent an INLINEASM block that is also considered a terminator instruction. There will likely be more bug fixes and optimizations to follow this, but we felt it had reached a point where we would like to switch to an incremental development model. Patch by Craig Topper, Alexander Ivchenko, Mikhail Dvoretckii Differential Revision: https://reviews.llvm.org/D53765 llvm-svn: 353563
* [CodeExtractor] Restore outputs after creating exit stubsVedant Kumar2019-02-081-35/+44
| | | | | | | | | | | | | | | | | When CodeExtractor saves the result of InvokeInst at the first insertion point of the 'normal destination' basic block, this block can be omitted in the outlined region, so store is placed outside of the function. The suggested solution is to process saving outputs after creating exit stubs for new function, and stores will be placed in that blocks before return in this case. Patch by Sergei Kachkov! Fixes llvm.org/PR40455. Differential Revision: https://reviews.llvm.org/D57919 llvm-svn: 353562
* [InstrProf] Implement static profdata registrationReid Kleckner2019-02-081-32/+52
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: The motivating use case is eliminating duplicate profile data registered for the same inline function in two object files. Before this change, users would observe multiple symbol definition errors with VC link, but links with LLD would succeed. Users (Mozilla) have reported that PGO works well with clang-cl and LLD, but when using LLD without this static registration, we would get into a "relocation against a discarded section" situation. I'm not sure what happens in that situation, but I suspect that duplicate, unused profile information was retained. If so, this change will reduce the size of such binaries with LLD. Now, Windows uses static registration and is in line with all the other platforms. Reviewers: davidxl, wmi, inglorion, void, calixte Subscribers: mgorny, krytarowski, eraman, fedor.sergeev, hiraditya, #sanitizers, dmajor, llvm-commits Tags: #sanitizers, #llvm Differential Revision: https://reviews.llvm.org/D57929 llvm-svn: 353547
* ArgumentPromotion should copy all metadata to new FunctionTeresa Johnson2019-02-081-4/+1
| | | | | | | | | | | | | | | | | | | Summary: ArgumentPromotion had code to specifically move the dbg metadata over to the new function, but other metadata such as the function_entry_count !prof metadata was not. Replace code that moved dbg metadata with a call to copyMetadata. The old metadata is automatically removed when the old Function is removed. Reviewers: davidxl Subscribers: llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D57846 llvm-svn: 353537
* [DWARF] LLVM ERROR: Broken function found, while removing Debug Intrinsics.Carlos Alberto Enciso2019-02-081-3/+3
| | | | | | | | Check that when SimplifyCFG is flattening a 'br', all their debug intrinsic instructions are removed, including any dbg.label referencing a label associated with the basic blocks being removed. Differential Revision: https://reviews.llvm.org/D57444 llvm-svn: 353511
* [LoopSimplifyCFG] Use DTU.applyUpdates instead of insert/deleteEdgeMax Kazantsev2019-02-081-11/+22
| | | | | | | | | | | `insert/deleteEdge` methods in DTU can make updates incorrectly in some cases (see https://bugs.llvm.org/show_bug.cgi?id=40528), and it is recommended to use `applyUpdates` methods instead when it is needed to make a mass update in CFG. Differential Revision: https://reviews.llvm.org/D57316 Reviewed By: kuhar llvm-svn: 353502
* [CodeExtractor] Update function's assumption cache after extracting blocks ↵Sergey Dmitriev2019-02-084-31/+77
| | | | | | | | | | | | | | | | | | from it Summary: Assumption cache's self-updating mechanism does not correctly handle the case when blocks are extracted from the function by the CodeExtractor. As a result function's assumption cache may have stale references to the llvm.assume calls that were moved to the outlined function. This patch fixes this problem by removing extracted llvm.assume calls from the function’s assumption cache. Reviewers: hfinkel, vsk, fhahn, davidxl, sanjoy Reviewed By: hfinkel, vsk Subscribers: llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D57215 llvm-svn: 353500
* [InstCombine] Optimize `atomicrmw <op>, 0` into `load atomic` when possibleQuentin Colombet2019-02-073-0/+50
| | | | | | | | | | | | | This commit teaches InstCombine how to replace an atomicrmw operation into a simple load atomic. For a given `atomicrmw <op>`, this is possible when: 1. The ordering of that operation is compatible with a load (i.e., anything that doesn't have a release semantic). 2. <op> does not modify the value being stored Differential Revision: https://reviews.llvm.org/D57854 llvm-svn: 353471
* [LV] Remove unnecessary assignment to UserIC.Florian Hahn2019-02-071-1/+0
| | | | llvm-svn: 353469
* [InstCombine] Fix crashing from (icmp (bitcast ([su]itofp X)), Y)Sanjay Patel2019-02-071-29/+33
| | | | | | | | | | | | | | | This fixes a class of bugs introduced by D44367, which transforms various cases of icmp (bitcast ([su]itofp X)), Y to icmp X, Y. If the bitcast is between vector types with a different number of elements, the current code will produce bad IR along the lines of: icmp <N x i32> ..., <M x i32> <...>. This patch suppresses the transform if the bitcast changes the number of vector elements. Patch by: @AndrewScheidecker (Andrew Scheidecker) Differential Revision: https://reviews.llvm.org/D57871 llvm-svn: 353467
* [InstCombine] refactor folds for (icmp (bitcast X), Y); NFCISanjay Patel2019-02-072-77/+69
| | | | llvm-svn: 353462
OpenPOWER on IntegriCloud