summaryrefslogtreecommitdiffstats
path: root/llvm/lib/IR/Instructions.cpp
Commit message (Collapse)AuthorAgeFilesLines
...
* Drive-by fixes for LandingPad -> EHPadDavid Majnemer2015-08-041-1/+4
| | | | | | | | This change was done as an audit and is by inspection. The new EH system is still very much a work in progress. NFC for the landingpad case. llvm-svn: 243965
* New EH representation for MSVC compatibilityDavid Majnemer2015-07-311-0/+321
| | | | | | | | | | This introduces new instructions neccessary to implement MSVC-compatible exception handling support. Most of the middle-end and none of the back-end haven't been audited or updated to take them into account. Differential Revision: http://reviews.llvm.org/D11097 llvm-svn: 243766
* Revert the new EH instructionsDavid Majnemer2015-07-101-321/+0
| | | | | | This reverts commits r241888-r241891, I didn't mean to commit them. llvm-svn: 241893
* New EH representation for MSVC compatibilityDavid Majnemer2015-07-101-0/+321
| | | | | | | | | | | | | | | Summary: This introduces new instructions neccessary to implement MSVC-compatible exception handling support. Most of the middle-end and none of the back-end haven't been audited or updated to take them into account. Reviewers: rnk, JosephTremoulet, reames, nlewycky, rjmccall Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D11041 llvm-svn: 241888
* Add functions for adding and testing string attributes to CallInst. NFC.Akira Hatanaka2015-07-021-8/+6
| | | | | | | This change is needed later when I make changes to attach string function attributes to llvm.trap and llvm.debugtrap. llvm-svn: 241304
* Devirtualize Instruction::clone_implPete Cooper2015-06-241-48/+41
| | | | llvm-svn: 240588
* Move the personality function from LandingPadInst to FunctionDavid Majnemer2015-06-171-23/+15
| | | | | | | | | | | | | | | | | | | The personality routine currently lives in the LandingPadInst. This isn't desirable because: - All LandingPadInsts in the same function must have the same personality routine. This means that each LandingPadInst beyond the first has an operand which produces no additional information. - There is ongoing work to introduce EH IR constructs other than LandingPadInst. Moving the personality routine off of any one particular Instruction and onto the parent function seems a lot better than have N different places a personality function can sneak onto an exceptional function. Differential Revision: http://reviews.llvm.org/D10429 llvm-svn: 239940
* Rename NumOperands to make it clear its managed by the User. NFC.Pete Cooper2015-06-121-19/+20
| | | | | | | | | | | | | | | | | | | | | This is to try make it very clear that subclasses shouldn't be changing the value directly. Now that OperandList for normal instructions is computed using the NumOperands, its critical that the NumOperands is accurate or we could compute the wrong offset to the first operand. I looked over all places which update NumOperands and they are all safe. Hung off use User's don't use NumOperands to compute the OperandList so they are safe to continue to manipulate it. The only other User which changed it was GlobalVariable which has an optional init list but always allocated space for a single Use. It was correctly setting NumOperands to 1 before setting an initializer, and setting it to 0 after clearing the init list, so the order was safe. Added some comments to that code to make sure that this isn't changed in future without being aware of this constraint. Reviewed by Duncan Exon Smith. llvm-svn: 239621
* Replace all accesses to User::OperandList with getter and setter methods. NFC.Pete Cooper2015-06-121-7/+10
| | | | | | | | | | We don't want anyone to access OperandList directly as its going to be removed and computed instead. This uses getter's and setter's instead in which we can later change the underlying implementation of OperandList. Reviewed by Duncan Exon Smith. llvm-svn: 239620
* Stop returning a Use* from allocHungOffUses.Pete Cooper2015-06-101-13/+14
| | | | | | | | | This always just set the User::OperandList which is now set in that method instead of being returned. Reviewed by Duncan Exon Smith. llvm-svn: 239493
* Add User::growHungoffUses and use it to grow the hung off uses. NFC.Pete Cooper2015-06-101-30/+4
| | | | | | | | | | | | | PhiNode, SwitchInst, LandingPad and IndirectBr all had virtually identical logic for growing the hung off uses. Move it to User so that they can all call a single shared implementation. Their destructors were all empty after this change and were deleted. They all have virtual clone_impl methods which can be used as vtable anchors. Reviewed by Duncan Exon Smith. llvm-svn: 239492
* Delete User::dropHungOffUses and move it in to ~User which is the only ↵Pete Cooper2015-06-101-16/+0
| | | | | | | | | | | caller. NFC. Now that the subclasses which care about hung off uses let ~User clean it up, there's no need for a separate method. Just inline it to ~User and delete it. Reviewed by Duncan Exon Smith. llvm-svn: 239491
* Move the special Phi logic for hung off uses in to User::allocHungOffUses. NFC.Pete Cooper2015-06-101-12/+0
| | | | | | | | | | | | PhiNode's need to allocate space for an array of Use[N] and then BasicBlock*[N]. They had their own allocHungOffUses to handle all of this. This moves the logic in to User::allocHungOffUses and PhiNode passes in a bool to say to allocate the BB* space too. Reviewed by Duncan Exon Smith. llvm-svn: 239489
* [opaque pointer type] Explicitly store the pointee type of the result of a GEPDavid Blaikie2015-06-011-1/+2
| | | | | | | | Alternatively, this type could be derived on-demand whenever getResultElementType is called - if someone thinks that's the better choice (simple time/space tradeoff), I'm happy to give it a go. llvm-svn: 238716
* [IR] fptrunc-of-fptrunc isn't an EliminableCastPair.Ahmed Bougacha2015-05-291-1/+1
| | | | | | | Double and single rounding can produce different results. This is the IR counterpart to r228911. llvm-svn: 238531
* Use Op<0> accessor instead of OperandList for Instructions. NFCPete Cooper2015-05-211-5/+5
| | | | | | This is consistent with other uses of the operand list. I'm planning a future commit where this will actually matter. llvm-svn: 237967
* [opaque pointer type] Pass explicit type to Load instruction creation in ↵David Blaikie2015-05-201-5/+5
| | | | | | AutoUpgrade llvm-svn: 237838
* [opaque pointer type] LoadInst: assert that the explicit type matches the ↵David Blaikie2015-05-201-0/+1
| | | | | | implicit one llvm-svn: 237830
* [opaque pointer type] Pass the explicit function type down to the ↵David Blaikie2015-05-131-3/+4
| | | | | | instruction constructor when parsing invoke instructions llvm-svn: 237273
* [opaque pointer type] Track explicit GEP pointee type through in-memory IRDavid Blaikie2015-05-051-4/+5
| | | | llvm-svn: 236510
* [opaque pointer type] Store the value type of an allocaDavid Blaikie2015-04-291-8/+6
| | | | llvm-svn: 236175
* Recommit r235458: [opaque pointer type] Avoid using ↵David Blaikie2015-04-231-21/+16
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | PointerType::getElementType for a few cases of CallInst (reverted in r235533) Original commit message: "Calls to llvm::Value::mutateType are becoming extra-sensitive now that instructions have extra type information that will not be derived from operands or result type (alloca, gep, load, call/invoke, etc... ). The special-handling for mutateType will get more complicated as this work continues - it might be worth making mutateType virtual & pushing the complexity down into the classes that need special handling. But with only two significant uses of mutateType (vectorization and linking) this seems OK for now. Totally open to ideas/suggestions/improvements, of course. With this, and a bunch of exceptions, we can roundtrip an indirect call site through bitcode and IR. (a direct call site is actually trickier... I haven't figured out how to deal with the IR deserializer's lazy construction of Function/GlobalVariable decl's based on the type of the entity which means looking through the "pointer to T" type referring to the global)" The remapping done in ValueMapper for LTO was insufficient as the types weren't correctly mapped (though I was using the post-mapped operands, some of those operands might not have been mapped yet so the type wouldn't be post-mapped yet). Instead use the pre-mapped type and explicitly map all the types. llvm-svn: 235651
* Revert "[opaque pointer type] Avoid using PointerType::getElementType for a ↵David Blaikie2015-04-221-16/+21
| | | | | | | | | | | few cases of CallInst" This reverts commit r235458. It looks like this might be breaking something LTO-ish. Looking into it & will recommit with a fix/test case/etc once I've got more to go on. llvm-svn: 235533
* [opaque pointer type] Avoid using PointerType::getElementType for a few ↵David Blaikie2015-04-211-21/+16
| | | | | | | | | | | | | | | | | | | | | | | | cases of CallInst Calls to llvm::Value::mutateType are becoming extra-sensitive now that instructions have extra type information that will not be derived from operands or result type (alloca, gep, load, call/invoke, etc... ). The special-handling for mutateType will get more complicated as this work continues - it might be worth making mutateType virtual & pushing the complexity down into the classes that need special handling. But with only two significant uses of mutateType (vectorization and linking) this seems OK for now. Totally open to ideas/suggestions/improvements, of course. With this, and a bunch of exceptions, we can roundtrip an indirect call site through bitcode and IR. (a direct call site is actually trickier... I haven't figured out how to deal with the IR deserializer's lazy construction of Function/GlobalVariable decl's based on the type of the entity which means looking through the "pointer to T" type referring to the global) llvm-svn: 235458
* InstCombine: fold (sitofp (zext x)) to (uitofp x)Fiona Glaser2015-04-211-1/+4
| | | | | | | This is okay because the zext guarantees the high bit is zero, and so the value is unsigned. llvm-svn: 235364
* [opaque pointer types] Use the pointee type loaded from bitcode when ↵David Blaikie2015-04-171-2/+2
| | | | | | | | | | constructing a LoadInst Now (with a few carefully placed suppressions relating to general type serialization, etc) we can round trip a simple load through bitcode and textual IR without calling getElementType on a PointerType. llvm-svn: 235221
* [IR] Introduce a dereferenceable_or_null(N) attribute.Sanjoy Das2015-04-161-0/+12
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: If a pointer is marked as dereferenceable_or_null(N), LLVM assumes it is either `null` or `dereferenceable(N)` or both. This change only introduces the attribute and adds a token test case for the `llvm-as` / `llvm-dis`. It does not hook up other parts of the optimizer to actually exploit the attribute -- those changes will come later. For pointers in address space 0, `dereferenceable(N)` is now exactly equivalent to `dereferenceable_or_null(N)` && `nonnull`. For other address spaces, `dereferenceable(N)` is potentially weaker than `dereferenceable_or_null(N)` && `nonnull` (since we could have a null `dereferenceable(N)` pointer). The motivating case for this change is Java (and other managed languages), where pointers are either `null` or dereferenceable up to some usually known-at-compile-time constant offset. Reviewers: rafael, hfinkel Reviewed By: hfinkel Subscribers: nicholas, llvm-commits Differential Revision: http://reviews.llvm.org/D8650 llvm-svn: 235132
* [opaque pointer type] Avoid using PointerType::getElementType when parsing IRDavid Blaikie2015-04-061-5/+3
| | | | | | | | | | A few calls are left in for error checking - but I'm commenting those out & trying to build some IR tests (aiming for Argument Promotion to start with). When I get any of these tests passing I may add flag to disable the checking so I can add tests that pass with the assertion in place. llvm-svn: 234206
* [opaque pointer type] Change GetElementPtrInst::getIndexedType to take the ↵David Blaikie2015-03-301-11/+7
| | | | | | | | | | pointee type This pushes the use of PointerType::getElementType up into several callers - I'll essentially just have to keep pushing that up the stack until I can eliminate every call to it... llvm-svn: 233604
* Refactor: Simplify boolean expressions in llvm IRDavid Blaikie2015-03-231-28/+22
| | | | | | | | | | | Simplify boolean expressions using `true` and `false` with `clang-tidy` Patch by Richard Thomson with a few other simplifications to fix else-after-returns in the surrounding code. Differential Revision: http://reviews.llvm.org/D8527 llvm-svn: 233005
* DataLayout is mandatory, update the API to reflect it with references.Mehdi Amini2015-03-101-12/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: Now that the DataLayout is a mandatory part of the module, let's start cleaning the codebase. This patch is a first attempt at doing that. This patch is not exactly NFC as for instance some places were passing a nullptr instead of the DataLayout, possibly just because there was a default value on the DataLayout argument to many functions in the API. Even though it is not purely NFC, there is no change in the validation. I turned as many pointer to DataLayout to references, this helped figuring out all the places where a nullptr could come up. I had initially a local version of this patch broken into over 30 independant, commits but some later commit were cleaning the API and touching part of the code modified in the previous commits, so it seemed cleaner without the intermediate state. Test Plan: Reviewers: echristo Subscribers: llvm-commits From: Mehdi Amini <mehdi.amini@apple.com> llvm-svn: 231740
* Instructions: Use delegated constructors to reduce duplicationBenjamin Kramer2015-03-051-153/+32
| | | | | | NFC. llvm-svn: 231411
* IR: SrcTy == DstTy doesn't imply that a cast is validDavid Majnemer2015-02-161-4/+0
| | | | | | Cast validity depends on the cast's kind, not just its types. llvm-svn: 229366
* InstCombine: propagate deref via new addDereferenceableAttrRamkumar Ramachandra2015-02-141-0/+12
| | | | | | | | | | | | | | | | | The "dereferenceable" attribute cannot be added via .addAttribute(), since it also expects a size in bytes. AttrBuilder#addAttribute or AttributeSet#addAttribute is wrapped by classes Function, InvokeInst, and CallInst. Add corresponding wrappers to AttrBuilder#addDereferenceableAttr. Having done this, propagate the dereferenceable attribute via gc.relocate, adding a test to exercise it. Note that -datalayout is required during execution over and above -instcombine, because InstCombine only optionally requires DataLayoutPass. Differential Revision: http://reviews.llvm.org/D7510 llvm-svn: 229265
* IR: Split Metadata from ValueDuncan P. N. Exon Smith2014-12-091-6/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Split `Metadata` away from the `Value` class hierarchy, as part of PR21532. Assembly and bitcode changes are in the wings, but this is the bulk of the change for the IR C++ API. I have a follow-up patch prepared for `clang`. If this breaks other sub-projects, I apologize in advance :(. Help me compile it on Darwin I'll try to fix it. FWIW, the errors should be easy to fix, so it may be simpler to just fix it yourself. This breaks the build for all metadata-related code that's out-of-tree. Rest assured the transition is mechanical and the compiler should catch almost all of the problems. Here's a quick guide for updating your code: - `Metadata` is the root of a class hierarchy with three main classes: `MDNode`, `MDString`, and `ValueAsMetadata`. It is distinct from the `Value` class hierarchy. It is typeless -- i.e., instances do *not* have a `Type`. - `MDNode`'s operands are all `Metadata *` (instead of `Value *`). - `TrackingVH<MDNode>` and `WeakVH` referring to metadata can be replaced with `TrackingMDNodeRef` and `TrackingMDRef`, respectively. If you're referring solely to resolved `MDNode`s -- post graph construction -- just use `MDNode*`. - `MDNode` (and the rest of `Metadata`) have only limited support for `replaceAllUsesWith()`. As long as an `MDNode` is pointing at a forward declaration -- the result of `MDNode::getTemporary()` -- it maintains a side map of its uses and can RAUW itself. Once the forward declarations are fully resolved RAUW support is dropped on the ground. This means that uniquing collisions on changing operands cause nodes to become "distinct". (This already happened fairly commonly, whenever an operand went to null.) If you're constructing complex (non self-reference) `MDNode` cycles, you need to call `MDNode::resolveCycles()` on each node (or on a top-level node that somehow references all of the nodes). Also, don't do that. Metadata cycles (and the RAUW machinery needed to construct them) are expensive. - An `MDNode` can only refer to a `Constant` through a bridge called `ConstantAsMetadata` (one of the subclasses of `ValueAsMetadata`). As a side effect, accessing an operand of an `MDNode` that is known to be, e.g., `ConstantInt`, takes three steps: first, cast from `Metadata` to `ConstantAsMetadata`; second, extract the `Constant`; third, cast down to `ConstantInt`. The eventual goal is to introduce `MDInt`/`MDFloat`/etc. and have metadata schema owners transition away from using `Constant`s when the type isn't important (and they don't care about referring to `GlobalValue`s). In the meantime, I've added transitional API to the `mdconst` namespace that matches semantics with the old code, in order to avoid adding the error-prone three-step equivalent to every call site. If your old code was: MDNode *N = foo(); bar(isa <ConstantInt>(N->getOperand(0))); baz(cast <ConstantInt>(N->getOperand(1))); bak(cast_or_null <ConstantInt>(N->getOperand(2))); bat(dyn_cast <ConstantInt>(N->getOperand(3))); bay(dyn_cast_or_null<ConstantInt>(N->getOperand(4))); you can trivially match its semantics with: MDNode *N = foo(); bar(mdconst::hasa <ConstantInt>(N->getOperand(0))); baz(mdconst::extract <ConstantInt>(N->getOperand(1))); bak(mdconst::extract_or_null <ConstantInt>(N->getOperand(2))); bat(mdconst::dyn_extract <ConstantInt>(N->getOperand(3))); bay(mdconst::dyn_extract_or_null<ConstantInt>(N->getOperand(4))); and when you transition your metadata schema to `MDInt`: MDNode *N = foo(); bar(isa <MDInt>(N->getOperand(0))); baz(cast <MDInt>(N->getOperand(1))); bak(cast_or_null <MDInt>(N->getOperand(2))); bat(dyn_cast <MDInt>(N->getOperand(3))); bay(dyn_cast_or_null<MDInt>(N->getOperand(4))); - A `CallInst` -- specifically, intrinsic instructions -- can refer to metadata through a bridge called `MetadataAsValue`. This is a subclass of `Value` where `getType()->isMetadataTy()`. `MetadataAsValue` is the *only* class that can legally refer to a `LocalAsMetadata`, which is a bridged form of non-`Constant` values like `Argument` and `Instruction`. It can also refer to any other `Metadata` subclass. (I'll break all your testcases in a follow-up commit, when I propagate this change to assembly.) llvm-svn: 223802
* Revert "Move function to obtain branch weights into the BranchInst class. NFC."Juergen Ributzka2014-12-091-20/+0
| | | | | | This reverts commit r223784 and copies the 'ExtractBranchMetadata' to CodeGenPrepare. llvm-svn: 223795
* Move function to obtain branch weights into the BranchInst class. NFC.Juergen Ributzka2014-12-091-0/+20
| | | | | | Make this function available to other parts of LLVM. llvm-svn: 223784
* Revert r220349 to re-instate r220277 with a fix for PR21330 -- quiteChandler Carruth2014-11-251-0/+23
| | | | | | | | | | | | | | | | | | | | | | | | | 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
* Use nullptr instead of NULL for variadic sentinelsReid Kleckner2014-11-131-3/+3
| | | | | | | | | | Windows defines NULL to 0, which when used as an argument to a variadic function, is not a null pointer constant. As a result, Clang's -Wsentinel fires on this code. Using '0' would be wrong on most 64-bit platforms, but both MSVC and Clang make it work on Windows. Sidestep the issue with nullptr. llvm-svn: 221940
* Revert "IR: MDNode => Value"Duncan P. N. Exon Smith2014-11-111-2/+3
| | | | | | | | | | | | | | | | | Instead, we're going to separate metadata from the Value hierarchy. See PR21532. This reverts commit r221375. This reverts commit r221373. This reverts commit r221359. This reverts commit r221167. This reverts commit r221027. This reverts commit r221024. This reverts commit r221023. This reverts commit r220995. This reverts commit r220994. llvm-svn: 221711
* IR: MDNode => Value: Instruction::getMetadata()Duncan P. N. Exon Smith2014-11-011-3/+2
| | | | | | | | | | Change `Instruction::getMetadata()` to return `Value` as part of PR21433. Update most callers to use `Instruction::getMDNode()`, which wraps the result in a `cast_or_null<MDNode>`. llvm-svn: 221024
* Revert "Teach the load analysis to allow finding available values which ↵Hans Wennborg2014-10-211-23/+0
| | | | | | | | require" (r220277) This seems to have caused PR21330. llvm-svn: 220349
* Teach the load analysis to allow finding available values which requireChandler Carruth2014-10-211-0/+23
| | | | | | | | | | | | | | | | | | | | 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: 220277
* Use dyn_cast<> instead of isa<> and cast<>Matt Arsenault2014-09-151-1/+2
| | | | llvm-svn: 217796
* Change name of copyFlags() to copyIRFlags(). Add convenience method for ↵Sanjay Patel2014-09-031-1/+18
| | | | | | | | | | logical 'and' of all flags. NFC. Adding 'IR' to the names in an attempt to be less ambiguous about the flags we're dealing with here. The 'and' method is needed by the SLPVectorizer (PR20802) and possibly other passes. llvm-svn: 217004
* Fix a logic bug when copying fast-math flags.Sanjay Patel2014-09-021-1/+1
| | | | | | | | | | | | | "Setting" does not equal "copying". This bug has sat dormant for 2 reasons: 1. The unit test was not adequate. 2. Every current user of the "copyFastMathFlags" API is operating on a new instruction. (ie, all existing fast-math flags are off). If you copy flags to an existing instruction that has some flags on already, you will not necessarily turn them off as expected. I uncovered this bug while trying to implement a fix for PR20802. llvm-svn: 216939
* Add a convenience method to copy wrapping, exact, and fast-math flags (NFC).Sanjay Patel2014-09-011-0/+16
| | | | | | | | | | | | | | The loop vectorizer preserves wrapping, exact, and fast-math properties of scalar instructions. This patch adds a convenience method to make that operation easier because we need to do this in the loop vectorizer, SLP vectorizer, and possibly other places. Although this is a 'no functional change' patch, I've added a testcase to verify that the exact flag is preserved by the loop vectorizer. The wrapping and fast-math flags are already checked in existing testcases. Differential Revision: http://reviews.llvm.org/D5138 llvm-svn: 216886
* Add CreatePointerBitCastOrAddrSpaceCast to IRBuilder and co.Matt Arsenault2014-07-141-8/+26
| | | | llvm-svn: 212962
* IR: add "cmpxchg weak" variant to support permitted failure.Tim Northover2014-06-131-9/+12
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This commit adds a weak variant of the cmpxchg operation, as described in C++11. A cmpxchg instruction with this modifier is permitted to fail to store, even if the comparison indicated it should. As a result, cmpxchg instructions must return a flag indicating success in addition to their original iN value loaded. Thus, for uniformity *all* cmpxchg instructions now return "{ iN, i1 }". The second flag is 1 when the store succeeded. At the DAG level, a new ATOMIC_CMP_SWAP_WITH_SUCCESS node has been added as the natural representation for the new cmpxchg instructions. It is a strong cmpxchg. By default this gets Expanded to the existing ATOMIC_CMP_SWAP during Legalization, so existing backends should see no change in behaviour. If they wish to deal with the enhanced node instead, they can call setOperationAction on it. Beware: as a node with 2 results, it cannot be selected from TableGen. Currently, no use is made of the extra information provided in this patch. Test updates are almost entirely adapting the input IR to the new scheme. Summary for out of tree users: ------------------------------ + Legacy Bitcode files are upgraded during read. + Legacy assembly IR files will be invalid. + Front-ends must adapt to different type for "cmpxchg". + Backends should be unaffected by default. llvm-svn: 210903
* InstCombine: Canonicalize addrspacecast between different element typesJingyue Wu2014-06-061-12/+6
| | | | | | | | | | | | | | | | addrspacecast X addrspace(M)* to Y addrspace(N)* --> bitcast X addrspace(M)* to Y addrspace(M)* addrspacecast Y addrspace(M)* to Y addrspace(N)* Updat all affected tests and add several new tests in addrspacecast.ll. This patch is based on http://reviews.llvm.org/D2186 (authored by Matt Arsenault) with fixes and more tests. llvm-svn: 210375
OpenPOWER on IntegriCloud