summaryrefslogtreecommitdiffstats
path: root/llvm/lib/Transforms
Commit message (Collapse)AuthorAgeFilesLines
* [ThinLTO] Auto-hide prevailing linkonce_odr only when all copies eligibleTeresa Johnson2019-05-101-5/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: We hit undefined references building with ThinLTO when one source file contained explicit instantiations of a template method (weak_odr) but there were also implicit instantiations in another file (linkonce_odr), and the latter was the prevailing copy. In this case the symbol was marked hidden when the prevailing linkonce_odr copy was promoted to weak_odr. It led to unsats when the resulting shared library was linked with other code that contained a reference (expecting to be resolved due to the explicit instantiation). Add a CanAutoHide flag to the GV summary to allow the thin link to identify when all copies are eligible for auto-hiding (because they were all originally linkonce_odr global unnamed addr), and only do the auto-hide in that case. Most of the changes here are due to plumbing the new flag through the bitcode and llvm assembly, and resulting test changes. I augmented the existing auto-hide test to check for this situation. Reviewers: pcc Subscribers: mehdi_amini, inglorion, eraman, dexonsmith, arphaman, dang, llvm-commits, steven_wu, wmi Tags: #llvm Differential Revision: https://reviews.llvm.org/D59709 llvm-svn: 360466
* Add InstCombine::visitFNeg(...)Cameron McInally2019-05-102-0/+10
| | | | | | Differential Revision: https://reviews.llvm.org/D61784 llvm-svn: 360461
* [SLP] Refactor VectorizableTree to use unique_ptr.Simon Pilgrim2019-05-101-48/+67
| | | | | | | | | | This patch fixes the TreeEntry dangling pointer issue caused by reallocations of VectorizableTree. Committed on behalf of @vporpo (Vasileios Porpodas) Differential Revision: https://reviews.llvm.org/D61706 llvm-svn: 360456
* [LSR] Tweak setup cost depth threshold to 10.Amara Emerson2019-05-101-1/+1
| | | | | | | | | | The original change introduced a depth limit of 7 which caused a 22% regression in the Swift MapReduceLazyCollection & Ackermann benchmarks. This new threshold still ensures that the original test case doesn't hang. rdar://50359639 llvm-svn: 360444
* [InferAddressSpaces] Enhance the handling of cosntexpr.Michael Liao2019-05-101-3/+10
| | | | | | | | | | | | | | | | | | | | | | | | | Summary: - Constant expressions may not be added in strict postorder as the forward instruction scan order. Thus, for a constant express (CE0), if its operand (CE1) is used in an previous instruction, they are not in postorder. However, different from `cloneInstructionWithNewAddressSpace`, `cloneConstantExprWithNewAddressSpace` doesn't bookkeep uninferred instructions for later resolving. That results in failure of inferring constant address. - This patch adds the support to infer constant expression operand recursively, since there won't be loop, if that operand is another constant expression. Reviewers: arsenm Subscribers: jholewinski, jvesely, wdng, nhaehnle, hiraditya, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D61760 llvm-svn: 360431
* [DebugInfo] Use zero linenos for debug intrinsics when promoting dbg.declareJeremy Morse2019-05-101-9/+26
| | | | | | | | | | | | | | | | | | | | In certain circumstances, optimizations pick line numbers from debug intrinsic instructions as the new location for altered instructions. This is problematic because the line number of a debugging intrinsic is meaningless (it doesn't produce any machine instruction), only the scope information is valid. The result can be the line number of a variable declaration "leaking" into real code from debugging intrinsics, making the line table un-necessarily jumpy, and potentially different with / without variable locations. Fix this by using zero line numbers when promoting dbg.declare intrinsics into dbg.values: this is safe for debug intrinsics as their line numbers are meaningless, and reduces the scope for damage / misleading stepping when optimizations pick locations from the wrong place. Differential Revision: https://reviews.llvm.org/D59272 llvm-svn: 360415
* [CodeGenPrepare] Limit recursion depth for collectBitPartsDavid Stuttard2019-05-091-7/+17
| | | | | | | | | | | | | | | | Summary: Seeing some issues for windows debug pathological cases with collectBitParts recursion (1525 levels of recursion!) Setting the limit to 64 as this should be sufficient - passes all lit cases Subscribers: llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D61728 Change-Id: I7f44cdc6c1badf1c2ccbf1b0c4b6afe27ecb39a1 llvm-svn: 360347
* [InstCombine] When turning sext into zext due to known bits, return the new ↵Craig Topper2019-05-081-4/+2
| | | | | | | | | | | | ZExt instead of calling replaceinstuseswith The worklist loop that we're returning back to should be able to do the repacement itself. This is how we normally do replacements. My main motivation was that I observed that we weren't preserving the name of the result when we do this transform. The replacement code in the worklist loop will call takeName as part of the replacement. Differential Revision: https://reviews.llvm.org/D61695 llvm-svn: 360284
* [NewPassManager] Add tuning option: SLPVectorization [NFC].Alina Sbirlea2019-05-082-4/+5
| | | | | | | | | | | | | | Summary: Mirror tuning option from old pass manager in new pass manager. Reviewers: chandlerc Subscribers: mehdi_amini, jlebar, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D61616 llvm-svn: 360276
* [MemorySSA] Teach LoopSimplify to preserve MemorySSA.Alina Sbirlea2019-05-089-43/+104
| | | | | | | | | | | | | | | Summary: Preserve MemorySSA in LoopSimplify, in the old pass manager, if the analysis is available. Do not preserve it in the new pass manager. Update tests. Subscribers: nemanjai, jlebar, javed.absar, Prazek, kbarton, zzheng, jsji, llvm-commits, george.burgess.iv, chandlerc Tags: #llvm Differential Revision: https://reviews.llvm.org/D60833 llvm-svn: 360270
* [Reassociation] Place moved instructions after landing padsDavid Greene2019-05-081-1/+23
| | | | | | | | | | | | | | | | | Reassociation's NegateValue moved instructions to the beginning of blocks (after PHIs) without checking for exception handling pads. It's possible for reassociation to move something into an exception handling block so we need to make sure we don't move things too early in the block. This change advances the insertion point past any exception handling pads. If the block we want to move into contains a catchswitch, we cannot move into it. In that case just create a new neg as if we had not found an existing neg to move. Differential Revision: https://reviews.llvm.org/D61089 llvm-svn: 360262
* [VPlan] Fix "value never used" static analyzer warning. NFCI.Simon Pilgrim2019-05-081-2/+1
| | | | llvm-svn: 360241
* [SCCP] Fix crash when trying to constant-fold terminators multiple times.Florian Hahn2019-05-081-1/+11
| | | | | | | | | | | | | | If we fold a branch/switch to an unconditional branch to another dead block we replace the branch with unreachable, to avoid attempting to fold the unconditional branch. Reviewers: davide, efriedma, mssimpso, jdoerfert Reviewed By: jdoerfert Differential Revision: https://reviews.llvm.org/D61300 llvm-svn: 360232
* revert r360162 as it breaks most of the buildbotsKostya Serebryany2019-05-072-21/+7
| | | | llvm-svn: 360190
* [InstCombine] Add new combine to add foldingRobert Lougher2019-05-071-1/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | (X | C1) + C2 --> (X | C1) ^ C1 iff (C1 == -C2) I verified the correctness using Alive: https://rise4fun.com/Alive/YNV This transform enables the following transform that already exists in instcombine: (X | Y) ^ Y --> X & ~Y As a result, the full expected transform is: (X | C1) + C2 --> X & ~C1 iff (C1 == -C2) There already exists the transform in the sub case: (X | Y) - Y --> X & ~Y However this does not trigger in the case where Y is constant due to an earlier transform: X - (-C) --> X + C With this new add fold, both the add and sub constant cases are handled. Patch by Chris Dawson. Differential Revision: https://reviews.llvm.org/D61517 llvm-svn: 360185
* [InstCombine] allow sinking fneg operands through an FP min/maxSanjay Patel2019-05-071-5/+5
| | | | | | | | | Fundamentally/generally, we should not have to rely on bailouts/crippling of folds. In this particular case, I think we always recognize the inverted predicate min/max pattern, so there should not be any loss of optimization. Codegen looks better because we are eliminating an fneg. llvm-svn: 360180
* [DebugInfo@O2][LoopVectorize] pr39024: Vectorized code linenos step through ↵Orlando Cazalet-Hyams2019-05-072-7/+21
| | | | | | | | | | | | | | | | | | | | | | | | | | loop even after completion Summary: Bug: https://bugs.llvm.org/show_bug.cgi?id=39024 The bug reports that a vectorized loop is stepped through 4 times and each step through the loop seemed to show a different path. I found two problems here: A) An incorrect line number on a preheader block (for.body.preheader) instruction causes a step into the loop before it begins. B) Instructions in the middle block have different line numbers which give the impression of another iteration. In this patch I give all of the middle block instructions the line number of the scalar loop latch terminator branch. This seems to provide the smoothest debugging experience because the vectorized loops will always end on this line before dropping into the scalar loop. To solve problem A I have altered llvm::SplitBlockPredecessors to accommodate loop header blocks. Reviewers: samsonov, vsk, aprantl, probinson, anemet, hfinkel Reviewed By: hfinkel Subscribers: bjope, jmellorcrummey, hfinkel, gbedwell, hiraditya, zzheng, llvm-commits Tags: #llvm, #debug-info Differential Revision: https://reviews.llvm.org/D60831 llvm-svn: 360162
* Test commit accessOrlando Cazalet-Hyams2019-05-071-2/+2
| | | | llvm-svn: 360125
* [SanitizerCoverage] Use different module ctor names for trace-pc-guard and ↵Fangrui Song2019-05-071-8/+15
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | inline-8bit-counters Fixes the main issue in PR41693 When both modes are used, two functions are created: `sancov.module_ctor`, `sancov.module_ctor.$LastUnique`, where $LastUnique is the current LastUnique counter that may be different in another module. `sancov.module_ctor.$LastUnique` belongs to the comdat group of the same name (due to the non-null third field of the ctor in llvm.global_ctors). COMDAT group section [ 9] `.group' [sancov.module_ctor] contains 6 sections: [Index] Name [ 10] .text.sancov.module_ctor [ 11] .rela.text.sancov.module_ctor [ 12] .text.sancov.module_ctor.6 [ 13] .rela.text.sancov.module_ctor.6 [ 23] .init_array.2 [ 24] .rela.init_array.2 # 2 problems: # 1) If sancov.module_ctor in this module is discarded, this group # has a relocation to a discarded section. ld.bfd and gold will # error. (Another issue: it is silently accepted by lld) # 2) The comdat group has an unstable name that may be different in # another translation unit. Even if the linker allows the dangling relocation # (with --noinhibit-exec), there will be many undesired .init_array entries COMDAT group section [ 25] `.group' [sancov.module_ctor.6] contains 2 sections: [Index] Name [ 26] .init_array.2 [ 27] .rela.init_array.2 By using different module ctor names, the associated comdat group names will also be different and thus stable across modules. Reviewed By: morehouse, phosek Differential Revision: https://reviews.llvm.org/D61510 llvm-svn: 360107
* Revert "Re-commit r357452: SimplifyCFG SinkCommonCodeFromPredecessors: Also ↵Jordan Rupprecht2019-05-061-15/+14
| | | | | | | | | | sink function calls without used results (PR41259)" This reverts r357452 (git commit 21eb771dcb5c11d7500fa6ad551c97a921997f05). This was causing strange optimization-related test failures on an internal test. Will followup with more details offline. llvm-svn: 360086
* [InstCombine] sink FP negation of operands through selectSanjay Patel2019-05-061-0/+12
| | | | | | | | | | | | | | We don't always get this: Cond ? -X : -Y --> -(Cond ? X : Y) ...even with the legacy IR form of fneg in the case with extra uses, and we miss matching with the newer 'fneg' instruction because we are expecting binops through the rest of the path. Differential Revision: https://reviews.llvm.org/D61604 llvm-svn: 360075
* Pull out repeated CI->getCalledFunction() calls. NFCI.Simon Pilgrim2019-05-061-2/+2
| | | | llvm-svn: 360070
* [InstCombine] reduce code duplication; NFCSanjay Patel2019-05-061-7/+7
| | | | llvm-svn: 360059
* [InstCombine] reduce code duplication; NFCISanjay Patel2019-05-061-22/+19
| | | | llvm-svn: 360051
* [LoadStoreVectorizer] vectorizeStoreChain - ensure we find a store type.Simon Pilgrim2019-05-061-1/+2
| | | | | | | | Properly initialize store type to null then ensure we find a real store type in the chain. Fixes scan-build null dereference warning and makes the code clearer. llvm-svn: 360031
* [SimplifyLibCalls] Simplify bcmp too.Clement Courbet2019-05-061-1/+19
| | | | | | | | | | | | | | Summary: Fixes PR40699. Reviewers: gchatelet Subscribers: hiraditya, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D61585 llvm-svn: 360021
* [DebugInfo] GlobalOpt DW_OP_deref_size instead of DW_OP_deref.Markus Lavin2019-05-061-2/+6
| | | | | | | | | | Optimization pass lib/Transforms/IPO/GlobalOpt.cpp needs to insert DW_OP_deref_size instead of DW_OP_deref to be compatible with big-endian targets for same reasons as in D59687. Differential Revision: https://reviews.llvm.org/D60611 llvm-svn: 360013
* [NFC] BasicBlock: refactor changePhiUses() out of replacePhiUsesWith(), use itRoman Lebedev2019-05-052-18/+10
| | | | | | | | | | | | | | | | | | | | | Summary: It is a common thing to loop over every `PHINode` in some `BasicBlock` and change old `BasicBlock` incoming block to a new `BasicBlock` incoming block. `replaceSuccessorsPhiUsesWith()` already had code to do that, it just wasn't a function. So outline it into a new function, and use it. Reviewers: chandlerc, craig.topper, spatel, danielcdh Reviewed By: craig.topper Subscribers: llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D61013 llvm-svn: 359996
* [NFC] PHINode: introduce replaceIncomingBlockWith() function, use itRoman Lebedev2019-05-052-23/+4
| | | | | | | | | | | | | | | | | | | | Summary: There is `PHINode::getBasicBlockIndex()`, `PHINode::setIncomingBlock()` and `PHINode::getNumOperands()`, but no function to replace every specified `BasicBlock*` predecessor with some other specified `BasicBlock*`. Clearly, there are a lot of places that could use that functionality. Reviewers: chandlerc, craig.topper, spatel, danielcdh Reviewed By: craig.topper Subscribers: llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D61011 llvm-svn: 359995
* [NFC] Instruction: introduce replaceSuccessorWith() function, use itRoman Lebedev2019-05-051-3/+1
| | | | | | | | | | | | | | | | | | | | Summary: There is `Instruction::getNumSuccessors()`, `Instruction::getSuccessor()` and `Instruction::setSuccessor()`, but no function to replace every specified `BasicBlock*` successor with some other specified `BasicBlock*`. I've found one place where it should clearly be used. Reviewers: chandlerc, craig.topper, spatel, danielcdh Reviewed By: craig.topper Subscribers: llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D61010 llvm-svn: 359994
* [NFC][Utils] deleteDeadLoop(): add an assert that exit block has some ↵Roman Lebedev2019-05-051-3/+7
| | | | | | | | | | | | | | | | | | | | | | | | | non-PHI instruction Summary: If `deleteDeadLoop()` is called on such a loop, that has "bad" exit block, one that e.g. has no terminator instruction, the `DIBuilder::insertDbgValueIntrinsic()` will be told to insert the Dbg Value Intrinsic after `nullptr` (since there is no first non-PHI instruction), which will cause it to not insert those instructions into any basic block. The instructions will be parent-less, and IR verifier will complain. It is rather obvious to track down the root cause when that happens, so let's just assert it never happens. Reviewers: sanjoy, davide, vsk Reviewed By: vsk Subscribers: llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D61008 llvm-svn: 359993
* [SLPVectorizer] Prefer pre-increments. NFCI.Simon Pilgrim2019-05-051-3/+3
| | | | llvm-svn: 359989
* [SLPVectorizer] Make getSpillCost() const. NFCI.Simon Pilgrim2019-05-051-2/+9
| | | | | | Ideally getTreeCost() should be const as well but non-const Type creation would need to be addressed first. llvm-svn: 359975
* Move Value *RHSCIOp def into the scope where its actually used. NFCI.Simon Pilgrim2019-05-051-2/+1
| | | | llvm-svn: 359973
* remove inalloca parameters in globalopt and simplify argpromotionBob Haarman2019-05-022-27/+31
| | | | | | | | | | | | | | | | | | | | | | | | | | Summary: Inalloca parameters require special handling in some optimizations. This change causes globalopt to strip the inalloca attribute from function parameters when it is safe to do so, removes the special handling for inallocas from argpromotion, and replaces it with a simple check that causes argpromotion to skip functions that receive inallocas (for when the pass is invoked on code that didn't run through globalopt first). This also avoids a case where argpromotion would incorrectly try to pass an inalloca in a register. Fixes PR41658. Reviewers: rnk, efriedma Reviewed By: rnk Subscribers: llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D61286 llvm-svn: 359743
* [PGO][CHR] A bug fix.Hiroshi Yamauchi2019-05-011-6/+21
| | | | | | | | | | | | | | | | Summary: Fix a transformation bug where two scopes share a common instrution to hoist. Reviewers: davidxl Reviewed By: davidxl Subscribers: llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D61405 llvm-svn: 359736
* [InstCombine] Limit a vector demanded elts rule which was producing invalid IR.Philip Reames2019-04-301-0/+12
| | | | | | | | The demanded elts rules introduced for GEPs in https://reviews.llvm.org/rL356293 replaced vector constants with undefs (by design). It turns out that the LangRef disallows such cases when indexing structs. The right fix is probably to relax the langref requirement, and update other passes to expect the result, but for the moment, limit the transform to avoid compiler crashes. This should fix https://bugs.llvm.org/show_bug.cgi?id=41624. llvm-svn: 359633
* [PassManagerBuilder] Add option for interleaved loops, for loop vectorize.Alina Sbirlea2019-04-301-4/+2
| | | | | | | | | | | | | | | | | Summary: Match NewPassManager behavior: add option for interleaved loops in the old pass manager, and use that instead of the flag used to disable loop unroll. No changes in the defaults. Reviewers: chandlerc Subscribers: mehdi_amini, jlebar, dmgreen, hsaito, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D61030 llvm-svn: 359615
* [SimplifyLibCalls] Clean up code (NFC)Evandro Menezes2019-04-301-6/+8
| | | | | | Fix pointer check after dereferencing (PR41665). llvm-svn: 359595
* MSan: handle llvm.lifetime.start intrinsicAlexander Potapenko2019-04-301-8/+54
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: When a variable goes into scope several times within a single function or when two variables from different scopes share a stack slot it may be incorrect to poison such scoped locals at the beginning of the function. In the former case it may lead to false negatives (see https://github.com/google/sanitizers/issues/590), in the latter - to incorrect reports (because only one origin remains on the stack). If Clang emits lifetime intrinsics for such scoped variables we insert code poisoning them after each call to llvm.lifetime.start(). If for a certain intrinsic we fail to find a corresponding alloca, we fall back to poisoning allocas for the whole function, as it's now impossible to tell which alloca was missed. The new instrumentation may slow down hot loops containing local variables with lifetime intrinsics, so we allow disabling it with -mllvm -msan-handle-lifetime-intrinsics=false. Reviewers: eugenis, pcc Subscribers: hiraditya, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D60617 llvm-svn: 359536
* [InstCombine] reduce code duplication; NFCSanjay Patel2019-04-291-5/+7
| | | | | | | | | | Follow-up to: rL359482 Avoid this potential problem throughout by giving the type a name and verifying the assumption that both operands are the same type. llvm-svn: 359485
* [InstCombine] visitFCmpInst - appease copy+paste pattern warning. NFCI.Simon Pilgrim2019-04-291-1/+1
| | | | | | | | PVS Studio's copy+paste recognizer was seeing this as a typo, technically Op0/Op1 in a fcmp should always be the same type, but we might as well avoid the issue. Reported in https://www.viva64.com/en/b/0629/ llvm-svn: 359482
* [BlockExtractor] Expose a constructor for the group extractionQuentin Colombet2019-04-291-3/+29
| | | | | | | | NFC Differential Revision: https://reviews.llvm.org/D60971 llvm-svn: 359463
* [BlockExtractor] Change the basic block separator from ',' to ';'Quentin Colombet2019-04-291-1/+1
| | | | | | | | | This change aims at making the file format be compatible with the way LLVM handles command line options. Differential Revision: https://reviews.llvm.org/D60970 llvm-svn: 359462
* [LoopSimplifyCFG] Suppress expensive DomTree verificationYevgeny Rouban2019-04-291-1/+7
| | | | | | | | | This patch makes verification level lower for builds with inexpensive checks. Differential Revision: https://reviews.llvm.org/D61055 llvm-svn: 359446
* [InferAddressSpaces] Add AS parameter to the pass factorySven van Haastregt2019-04-261-6/+11
| | | | | | | | | | | | | | This enables the pass to be used in the absence of TargetTransformInfo. When the argument isn't passed, the factory defaults to UninitializedAddressSpace and the flat address space is obtained from the TargetTransformInfo as before this change. Existing users won't have to change. Patch by Kevin Petit. Differential Revision: https://reviews.llvm.org/D60602 llvm-svn: 359290
* [GlobalOpt] Swap the expensive check for cold calls with the cheap TTI checkJustin Bogner2019-04-261-2/+2
| | | | | | | | | | | isValidCandidateForColdCC is much more expensive than TTI.useColdCCForColdCall, which by default just returns false. Avoid doing this work if we're not going to look at the answer anyway. This change is NFC, but I see significant compile time improvements on some code with pathologically many functions. llvm-svn: 359253
* Assigning to a local object in a return statement prevents copy elision. NFC.David Blaikie2019-04-251-4/+6
| | | | | | | | | | | | | | | | I added a diagnostic along the lines of `-Wpessimizing-move` to detect `return x = y` suppressing copy elision, but I don't know if the diagnostic is really worth it. Anyway, here are the places where my diagnostic reported that copy elision would have been possible if not for the assignment. P1155R1 in the post-San-Diego WG21 (C++ committee) mailing discusses whether WG21 should fix this pitfall by just changing the core language to permit copy elision in cases like these. (Kona update: The bulk of P1155 is proceeding to CWG review, but specifically *not* the parts that explored the notion of permitting copy-elision in these specific cases.) Reviewed By: dblaikie Author: Arthur O'Dwyer Differential Revision: https://reviews.llvm.org/D54885 llvm-svn: 359236
* [ObjC][ARC] Let ARC optimizer bail out if the number of pointer statesAkira Hatanaka2019-04-251-2/+42
| | | | | | | | | | | | | | | | | | | | it keeps track of becomes too large ARC optimizer does a top-down and a bottom-up traversal of the whole function to pair up retain and release instructions and remove them. This can be expensive if the number of instructions in the function and pointer states it tracks are large since it has to look at each pointer state and determine whether the instruction being visited can potentially use the pointer. This patch adds a command line option that sets a limit to the number of pointers it tracks. rdar://problem/49477063 Differential Revision: https://reviews.llvm.org/D61100 llvm-svn: 359226
* [Evaluator] Walk initial elements when handling load through bitcastRobert Lougher2019-04-251-38/+65
| | | | | | | | | | | | | | | | | | | | | | When evaluating a store through a bitcast, the evaluator tries to move the bitcast from the pointer onto the stored value. If the cast is invalid, it tries to "introspect" the type to get a valid cast by obtaining a pointer to the initial element (if the type is nested, this may require walking several initial elements). In some situations it is possible to get a bitcast on a load (e.g. with unions, where the bitcast may not be the same type as the store). However, equivalent logic to the store to introspect the type is missing. This patch add this logic. Note, when developing the patch I was unhappy with adding similar logic directly to the load case as it could get out of step. Instead, I have abstracted the "introspection" into a helper function, with the specifics being handled by a passed-in lambda function. Differential Revision: https://reviews.llvm.org/D60793 llvm-svn: 359205
OpenPOWER on IntegriCloud