summaryrefslogtreecommitdiffstats
path: root/llvm/lib/IR/Instructions.cpp
Commit message (Collapse)AuthorAgeFilesLines
* [PGO/SamplePGO][NFC] Move the function updateProfWeight from InstructionWei Mi2019-04-221-0/+44
| | | | | | | | | | | | | | | | | | | | | | to CallInst. The issue was raised here: https://reviews.llvm.org/D60903#1472783 The function Instruction::updateProfWeight is only used for CallInst in profile update. From the current interface, it is very easy to think that the function can also be used for branch instruction. However, Branch instruction does't need the scaling the function provides for branch_weights and VP (value profile), in addition, scaling may introduce inaccuracy for branch probablity. The patch moves the function updateProfWeight from Instruction class to CallInst to remove the confusion. The patch also changes the scaling of branch_weights from a loop to a block because we know that ProfileData for branch_weights of CallInst will only have two operands at most. Differential Revision: https://reviews.llvm.org/D60911 llvm-svn: 358900
* [InstCombine] canonicalize select shuffles by commutingSanjay Patel2019-03-311-0/+19
| | | | | | | | | | | | | | | | | | | | In PR41304: https://bugs.llvm.org/show_bug.cgi?id=41304 ...we have a case where we want to fold a binop of select-shuffle (blended) values. Rather than try to match commuted variants of the pattern, we can canonicalize the shuffles and check for mask equality with commuted operands. We don't produce arbitrary shuffle masks in instcombine, but select-shuffles are a special case that the backend is required to handle because we already canonicalize vector select to this shuffle form. So there should be no codegen difference from this change. It's possible that this improves CSE in IR though. Differential Revision: https://reviews.llvm.org/D60016 llvm-svn: 357366
* Remove large amount of empty lines mid-file. NFCKristina Brooks2019-03-031-9/+0
| | | | llvm-svn: 355286
* Implementation of asm-goto support in LLVMCraig Topper2019-02-081-0/+83
| | | | | | | | | | | | | | | | | | | | | | | | | 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
* [opaque pointer types] Pass function types to InvokeInst creation.James Y Knight2019-02-011-3/+3
| | | | | | | | | This cleans up all InvokeInst creation in LLVM to explicitly pass a function type rather than deriving it from the pointer's element-type. Differential Revision: https://reviews.llvm.org/D57171 llvm-svn: 352910
* [opaque pointer types] Pass function types to CallInst creation.James Y Knight2019-02-011-2/+2
| | | | | | | | | This cleans up all CallInst creation in LLVM to explicitly pass a function type rather than deriving it from the pointer's element-type. Differential Revision: https://reviews.llvm.org/D57170 llvm-svn: 352909
* [opaque pointer types] Add a FunctionCallee wrapper type, and use it.James Y Knight2019-02-011-4/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Recommit r352791 after tweaking DerivedTypes.h slightly, so that gcc doesn't choke on it, hopefully. Original Message: The FunctionCallee type is effectively a {FunctionType*,Value*} pair, and is a useful convenience to enable code to continue passing the result of getOrInsertFunction() through to EmitCall, even once pointer types lose their pointee-type. Then: - update the CallInst/InvokeInst instruction creation functions to take a Callee, - modify getOrInsertFunction to return FunctionCallee, and - update all callers appropriately. One area of particular note is the change to the sanitizer code. Previously, they had been casting the result of `getOrInsertFunction` to a `Function*` via `checkSanitizerInterfaceFunction`, and storing that. That would report an error if someone had already inserted a function declaraction with a mismatching signature. However, in general, LLVM allows for such mismatches, as `getOrInsertFunction` will automatically insert a bitcast if needed. As part of this cleanup, cause the sanitizer code to do the same. (It will call its functions using the expected signature, however they may have been declared.) Finally, in a small number of locations, callers of `getOrInsertFunction` actually were expecting/requiring that a brand new function was being created. In such cases, I've switched them to Function::Create instead. Differential Revision: https://reviews.llvm.org/D57315 llvm-svn: 352827
* Revert "[opaque pointer types] Add a FunctionCallee wrapper type, and use it."James Y Knight2019-01-311-4/+4
| | | | | | | | | This reverts commit f47d6b38c7a61d50db4566b02719de05492dcef1 (r352791). Seems to run into compilation failures with GCC (but not clang, where I tested it). Reverting while I investigate. llvm-svn: 352800
* [opaque pointer types] Add a FunctionCallee wrapper type, and use it.James Y Knight2019-01-311-4/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The FunctionCallee type is effectively a {FunctionType*,Value*} pair, and is a useful convenience to enable code to continue passing the result of getOrInsertFunction() through to EmitCall, even once pointer types lose their pointee-type. Then: - update the CallInst/InvokeInst instruction creation functions to take a Callee, - modify getOrInsertFunction to return FunctionCallee, and - update all callers appropriately. One area of particular note is the change to the sanitizer code. Previously, they had been casting the result of `getOrInsertFunction` to a `Function*` via `checkSanitizerInterfaceFunction`, and storing that. That would report an error if someone had already inserted a function declaraction with a mismatching signature. However, in general, LLVM allows for such mismatches, as `getOrInsertFunction` will automatically insert a bitcast if needed. As part of this cleanup, cause the sanitizer code to do the same. (It will call its functions using the expected signature, however they may have been declared.) Finally, in a small number of locations, callers of `getOrInsertFunction` actually were expecting/requiring that a brand new function was being created. In such cases, I've switched them to Function::Create instead. Differential Revision: https://reviews.llvm.org/D57315 llvm-svn: 352791
* [CallSite removal] Remove CallSite uses from InstCombine.Craig Topper2019-01-311-0/+15
| | | | | | | | | | | | Reviewers: chandlerc Reviewed By: chandlerc Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D57494 llvm-svn: 352771
* Reapply "IR: Add fp operations to atomicrmw"Matt Arsenault2019-01-221-0/+4
| | | | | | | This reapplies commits r351778 and r351782 with RISCV test fixes. llvm-svn: 351850
* Revert r351778: IR: Add fp operations to atomicrmwChandler Carruth2019-01-221-4/+0
| | | | | | | | | | | | | This broke the RISCV build, and even with that fixed, one of the RISCV tests behaves surprisingly differently with asserts than without, leaving there no clear test pattern to use. Generally it seems bad for hte IR to differ substantially due to asserts (as in, an alloca is used with asserts that isn't needed without!) and nothing I did simply would fix it so I'm reverting back to green. This also required reverting the RISCV build fix in r351782. llvm-svn: 351796
* IR: Add fp operations to atomicrmwMatt Arsenault2019-01-221-0/+4
| | | | | | Add just fadd/fsub for now. llvm-svn: 351778
* Update the file headers across all of the LLVM projects in the monorepoChandler Carruth2019-01-191-4/+3
| | | | | | | | | | | | | | | | | to reflect the new license. We understand that people may be surprised that we're moving the header entirely to discuss the new license. We checked this carefully with the Foundation's lawyer and we believe this is the correct approach. Essentially, all code in the project is now made available by the LLVM project under our new license, so you will see that the license headers include that license only. Some of our contributors have contributed code under our old license, and accordingly, we have retained a copy of our old license notice in the top-level files in each project and repository. llvm-svn: 351636
* [opaque pointer types] Update LoadInst creation APIs to consistentlyJames Y Knight2019-01-141-56/+15
| | | | | | | | | | accept a return-type argument. Note: this also adds a new C API and soft-deprecates the old C API. Differential Revision: https://reviews.llvm.org/D56558 llvm-svn: 351123
* [opaque pointer types] Update CallInst creation APIs to consistentlyJames Y Knight2019-01-141-17/+12
| | | | | | | | | | accept a callee-type argument. Note: this also adds a new C API and soft-deprecates the old C API. Differential Revision: https://reviews.llvm.org/D56556 llvm-svn: 351121
* [CallSite removal] Port `IndirectCallSiteVisitor` to use `CallBase` andChandler Carruth2019-01-071-0/+10
| | | | | | | | | | | update client code. Also rename it to use the more generic term `call` instead of something that could be confused with a praticular type. Differential Revision: https://reviews.llvm.org/D56183 llvm-svn: 350508
* [CallSite removal] Add and flesh out APIs on the new `CallBase` base class ↵Chandler Carruth2018-12-271-0/+21
| | | | | | | | | | | | | | | | | | | that previously were only available on the `CallSite` wrapper. Summary: This will make migrating code easier and generally seems like a good collection of API improvements. Some of these APIs seem like more consistent / better naming of existing ones. I've retained the old names for migration simplicit and am just adding the new ones in this commit. I'll try to garbage collect these once CallSite is gone. Subscribers: sanjoy, mcrosier, hiraditya, llvm-commits Differential Revision: https://reviews.llvm.org/D55638 llvm-svn: 350109
* [TI removal] Leverage the fact that TerminatorInst is gone to createChandler Carruth2018-11-221-31/+100
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | a normal base class that provides all common "call" functionality. This merges two complex CRTP mixins for the common "call" logic and common operand bundle logic into a single, normal base class of `CallInst` and `InvokeInst`. Going forward, users can typically `dyn_cast<CallBase>` and use the resulting API. No more need for the `CallSite` wrapper. I'm planning to migrate current usage of the wrapper to directly use the base class and then it can be removed, but those are simpler and much more incremental steps. The big change is to introduce this abstraction into the type system. I've tried to do some basic simplifications of the APIs that I couldn't really help but touch as part of this: - I've tried to organize the attribute API and bundle API into groups to make understanding the API of `CallBase` easier. Without this, I wasn't able to navigate the API sanely for all of the ways I needed to modify it. - I've added what seem like more clear and consistent APIs for getting at the called operand. These ended up being especially useful to consolidate the *numerous* duplicated code paths trying to do this. - I've largely reworked the organization and implementation of the APIs for computing the argument operands as they needed to change to work with the new subclass approach. To minimize any cost associated with this abstraction, I've moved the operand layout in memory to store the called operand last. This makes its position relative to the end of the operand array the same, regardless of the subclass. It should make it much cheaper to reference from the `CallBase` abstraction, and this is likely one of the most frequent things to query. We do still pay one abstraction penalty here: we have to branch to determine whether there are 0 or 2 extra operands when computing the end of the argument operand sequence. However, that seems both rare and should optimize well. I've implemented this in a way specifically designed to allow it to optimize fairly well. If this shows up in profiles, we can add overrides of the relevant methods to the subclasses that bypass this penalty. It seems very unlikely that this will be an issue as the code was *already* dealing with an ever present abstraction of whether or not there are operand bundles, so this isn't the first branch to go into the computation. I've tried to remove as much of the obvious vestigial API surface of the old CRTP implementation as I could, but I suspect there is further cleanup that should now be possible, especially around the operand bundle APIs. I'm leaving all of that for future work in this patch as enough things are changing here as-is. One thing that made this harder for me to reason about and debug was the pervasive use of unsigned values in subtraction and other arithmetic computations. I had to debug more than one unintentional wrap. I've switched a few of these to use `int` which seems substantially simpler, but I've held back from doing this more broadly to avoid creating confusing divergence within a single class's API. I also worked to remove all of the magic numbers used to index into operands, putting them behind named constants or putting them into a single method with a comment and strictly using the method elsewhere. This was necessary to be able to re-layout the operands as discussed above. Thanks to Ben for reviewing this (somewhat large and awkward) patch! Differential Revision: https://reviews.llvm.org/D54788 llvm-svn: 347452
* Use llvm::copy. NFCFangrui Song2018-11-171-4/+4
| | | | llvm-svn: 347126
* [IR] Add a dedicated FNeg IR InstructionCameron McInally2018-11-131-0/+57
| | | | | | | | | | | The IEEE-754 Standard makes it clear that fneg(x) and fsub(-0.0, x) are two different operations. The former is a bitwise operation, while the latter is an arithmetic operation. This patch creates a dedicated FNeg IR Instruction to model that behavior. Differential Revision: https://reviews.llvm.org/D53877 llvm-svn: 346774
* Fix -Wsign-compare warningFangrui Song2018-11-091-1/+1
| | | | llvm-svn: 346515
* [CostModel] Add SK_ExtractSubvector handling to getInstructionThroughput ↵Simon Pilgrim2018-11-091-0/+29
| | | | | | | | (PR39368) Add ShuffleVectorInst::isExtractSubvectorMask helper to match shuffle masks. llvm-svn: 346510
* [IR] add optional parameter for copying IR flags to compare instructionsSanjay Patel2018-11-071-3/+6
| | | | | | | | As shown, this is used to eliminate redundant code in InstCombine, and there are more cases where we should be using this pattern, but we're currently unintentionally dropping flags. llvm-svn: 346282
* [IR] remove fake binop query for fnegSanjay Patel2018-11-011-19/+0
| | | | | | | | | | | | | | | | We want to remove this fneg API because it would silently fail if we add an actual fneg instruction to IR (as proposed in D53877 ). We have a newer 'match' API that makes checking for these patterns simpler. It also works with vectors that may include undef elements in constants. If any out-of-tree users need updating, they can model their code changes on this commit: https://reviews.llvm.org/rL345295 llvm-svn: 345904
* [IR] Fix -Wunused-function after r345052Fangrui Song2018-10-231-7/+0
| | | | llvm-svn: 345057
* [IR] remove fake binop queries for not/negSanjay Patel2018-10-231-39/+0
| | | | | | | | | | | | | | | | | | | | | | | The initial motivation is that we want to remove the fneg API because that would silently fail if we add an actual fneg instruction to IR. The same would be true for the integer ops, so we might as well get rid of these too. We have a newer 'match' API that makes checking for these patterns simpler. It also works with vectors that may include undef elements in constants. If any out-of-tree users need updating, they can model their code changes on these commits: rL345050 rL345043 rL345042 rL345041 rL345036 rL345030 llvm-svn: 345052
* [TI removal] Remove `TerminatorInst` from the IR type system!Chandler Carruth2018-10-191-80/+73
| | | | llvm-svn: 344769
* IR: Move AtomicRMW string names into classMatt Arsenault2018-10-021-0/+31
| | | | | | This will be used to improve error messages in a future commit. llvm-svn: 343647
* [IR] add shuffle query for vector concatenationSanjay Patel2018-09-201-0/+17
| | | | | | This can be used for combining and in the vectorizers/cost models. llvm-svn: 342653
* [IR] fix declaration of shuffle maskSanjay Patel2018-08-301-1/+1
| | | | | | An address sanitizer bot flagged this as a potential bug. llvm-svn: 341084
* [IR] add shuffle queries for identity extend/extract Sanjay Patel2018-08-301-9/+48
| | | | | | | | | | | | | | | This was one of the potential follow-ups suggested in D48236, and these will be used to make matching the patterns in PR38691 cleaner: https://bugs.llvm.org/show_bug.cgi?id=38691 About the vocabulary: in the DAG, these would be concat_vector with an undef operand or extract_subvector. Alternate names are discussed in the review, but I think these are familiar/good enough to proceed. Once we have uses of them in code, we might adjust if there are better options. https://reviews.llvm.org/D51392 llvm-svn: 341075
* [IR] Begin removal of TerminatorInst by removing successor manipulation.Chandler Carruth2018-08-261-40/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The core get and set routines move to the `Instruction` class. These routines are only valid to call on instructions which are terminators. The iterator and *generic* range based access move to `CFG.h` where all the other generic successor and predecessor access lives. While moving the iterator here, simplify it using the iterator utilities LLVM provides and updates coding style as much as reasonable. The APIs remain pointer-heavy when they could better use references, and retain the odd behavior of `operator*` and `operator->` that is common in LLVM iterators. Adjusting this API, if desired, should be a follow-up step. Non-generic range iteration is added for the two instructions where there is an especially easy mechanism and where there was code attempting to use the range accessor from a specific subclass: `indirectbr` and `br`. In both cases, the successors are contiguous operands and can be easily iterated via the operand list. This is the first major patch in removing the `TerminatorInst` type from the IR's instruction type hierarchy. This change was discussed in an RFC here and was pretty clearly positive: http://lists.llvm.org/pipermail/llvm-dev/2018-May/123407.html There will be a series of much more mechanical changes following this one to complete this move. Differential Revision: https://reviews.llvm.org/D47467 llvm-svn: 340698
* [IR Verifier] Do not allow bitcast of pointer to vector of pointers and vice ↵Serguei Katkov2018-08-211-6/+8
| | | | | | | | | | | | | | | | | | versa. LangRef for BitCast requires that "The bit sizes of value and the destination type, ty2, must be identical". Currently verifier allows BitCast of pointer to vector of pointers so that the sizes are different. This change fixes that. Reviewers: arsenm Reviewed By: arsenm Subscribers: llvm-commits, wdng Differential Revision: https://reviews.llvm.org/D50886 llvm-svn: 340249
* Remove trailing spaceFangrui Song2018-07-301-91/+91
| | | | | | sed -Ei 's/[[:space:]]+$//' include/**/*.{def,h,td} lib/**/*.{cpp,h} llvm-svn: 338293
* Improve ConvertDebugDeclareToDebugValueBjorn Pettersson2018-06-261-0/+16
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: This is a follow-up to r334830 and r335031. In the valueCoversEntireFragment check we now also handle the situation when there is a variable length array (VLA) involved, and the length of the array has been reduced to a constant. The ConvertDebugDeclareToDebugValue functions that are related to PHI nodes and load instructions now avoid inserting dbg.value intrinsics when the value does not, for certain, cover the variable/fragment that should be described. In r334830 we assumed that the value always covered the entire var/fragment and we had assertions in the code to show that assumption. However, those asserts failed when compiling code with VLAs, so we removed the asserts in r335031. Now when we know that the valueCoversEntireFragment check can fail also for PHI/Load instructions we avoid to insert the faulty dbg.value intrinsic in such situations. Compared to the Store instruction scenario we simply drop the dbg.value here (as the variable does not change its value due to PHI/Load, so an earlier dbg.value describing the variable should still be valid). Reviewers: aprantl, vsk, efriedma Reviewed By: aprantl Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D48547 llvm-svn: 335580
* [IR] move shuffle mask queries from TTI to ShuffleVectorInstSanjay Patel2018-06-191-2/+104
| | | | | | | | | | | | | | | | The optimizer is getting smarter (eg, D47986) about differentiating shuffles based on its mask values, so we should make queries on the mask constant operand generally available to avoid code duplication. We'll probably use this soon in the vectorizers and instcombine (D48023 and https://bugs.llvm.org/show_bug.cgi?id=37806). We might clean up TTI a bit more once all of its current 'SK_*' options are covered. Differential Revision: https://reviews.llvm.org/D48236 llvm-svn: 335067
* Remove @brief commands from doxygen comments, too.Adrian Prantl2018-05-011-2/+2
| | | | | | | | | | | | | | | | | This is a follow-up to r331272. We've been running doxygen with the autobrief option for a couple of years now. This makes the \brief markers into our comments redundant. Since they are a visual distraction and we don't want to encourage more \brief markers in new code either, this patch removes them all. Patch produced by for i in $(git grep -l '\@brief'); do perl -pi -e 's/\@brief //g' $i & done https://reviews.llvm.org/D46290 llvm-svn: 331275
* [InstCombine] Allow fptrunc (fpext X)) to be reduced to a single fpext/ftruncCraig Topper2018-03-021-7/+1
| | | | | | | | | | If we are only truncating bits from the extend we should be able to just use a smaller extend. If we are truncating more than the extend we should be able to just use a fptrunc since the presense of the fpextend shouldn't affect rounding. Differential Revision: https://reviews.llvm.org/D43970 llvm-svn: 326595
* Syndicate duplicate code between CallInst and InvokeInstSerge Guelton2018-02-221-237/+23
| | | | | | | | NFC intended, syndicate common code to a parametric base class. Part of the original problem is that InvokeInst is a TerminatorInst, unlike CallInst. the problem is solved by introducing a parametrized class paramtertized by its base. Differential Revision: https://reviews.llvm.org/D40727 llvm-svn: 325778
* Rename and move utility function getLatchPredicateForGuard. NFC.Serguei Katkov2018-02-091-0/+23
| | | | | | | Rename getLatchPredicateForGuard to more common name getFlippedStrictnessPredicate and move it to ICmpInst class. llvm-svn: 324717
* Re-enable "[SCEV] Make isLoopEntryGuardedByCond a bit smarter"Max Kazantsev2018-02-071-0/+14
| | | | | | | | | The failures happened because of assert which was overconfident about SCEV's proving capabilities and is generally not valid. Differential Revision: https://reviews.llvm.org/D42835 llvm-svn: 324473
* Revert [SCEV] Make isLoopEntryGuardedByCond a bit smarterSerguei Katkov2018-02-071-14/+0
| | | | | | | | Revert rL324453 commit which causes buildbot failures. Differential Revision: https://reviews.llvm.org/D42835 llvm-svn: 324462
* [SCEV] Make isLoopEntryGuardedByCond a bit smarterMax Kazantsev2018-02-071-0/+14
| | | | | | | | | | | Sometimes `isLoopEntryGuardedByCond` cannot prove predicate `a > b` directly. But it is a common situation when `a >= b` is known from ranges and `a != b` is known from a dominating condition. Thia patch teaches SCEV to sum these facts together and prove strict comparison via non-strict one. Differential Revision: https://reviews.llvm.org/D42835 llvm-svn: 324453
* Fix invalid ptrtoint in InstCombineYichao Yu2017-10-221-2/+5
| | | | | | | | | | | | | | | | | | | Summary: It's unclear if this is the only thing we can do but at least this is consistent with the check of address space agreement in `isBitCastable`. The code is used at least in both instcombine and jumpthreading though I could only find a way to trigger the invalid cast in instcombine. Reviewers: loladiro, sanjoy, majnemer Reviewed By: sanjoy Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D34335 llvm-svn: 316302
* Minor refactoring regarding Cast::isNoopCast(), NFCMikael Holmen2017-10-051-25/+3
| | | | | | | | | | | | | | | | | | | | | Summary: FastISel::hasTrivialKill() was the only user of the "IntPtrTy" version of Cast::isNoopCast(). According to review comments in D37894 we could instead use the "DataLayout" version of the method, and thus get rid of the "IntPtrTy" versions of isNoopCast() completely. With the above done, the remaining isNoopCast() could then be simplified a bit more. Reviewers: arsenm Reviewed By: arsenm Subscribers: wdng, llvm-commits Differential Revision: https://reviews.llvm.org/D38497 llvm-svn: 314969
* [Lint] Avoid failed assertion by fetching the proper pointer typeMikael Holmen2017-10-031-10/+18
| | | | | | | | | | | | | | | | | | | | | Summary: When checking if a constant expression is a noop cast we fetched the IntPtrType by doing DL->getIntPtrType(V->getType())). However, there can be cases where V doesn't return a pointer, and then getIntPtrType() triggers an assertion. Now we pass DataLayout to isNoopCast so the method itself can determine what the IntPtrType is. Reviewers: arsenm Reviewed By: arsenm Subscribers: wdng, llvm-commits Differential Revision: https://reviews.llvm.org/D37894 llvm-svn: 314763
* Enhance synchscope representationKonstantin Zhuravlyov2017-07-111-34/+34
| | | | | | | | | | | | | | | | | | | | | | | | | | | OpenCL 2.0 introduces the notion of memory scopes in atomic operations to global and local memory. These scopes restrict how synchronization is achieved, which can result in improved performance. This change extends existing notion of synchronization scopes in LLVM to support arbitrary scopes expressed as target-specific strings, in addition to the already defined scopes (single thread, system). The LLVM IR and MIR syntax for expressing synchronization scopes has changed to use *syncscope("<scope>")*, where <scope> can be "singlethread" (this replaces *singlethread* keyword), or a target-specific name. As before, if the scope is not specified, it defaults to CrossThread/System scope. Implementation details: - Mapping from synchronization scope name/string to synchronization scope id is stored in LLVM context; - CrossThread/System and SingleThread scopes are pre-defined to efficiently check for known scopes without comparing strings; - Synchronization scope names are stored in SYNC_SCOPE_NAMES_BLOCK in the bitcode. Differential Revision: https://reviews.llvm.org/D21723 llvm-svn: 307722
* [IR] Make use of ↵Craig Topper2017-07-091-4/+2
| | | | | | Type::isPtrOrPtrVectorTy/isIntOrIntVectorTy/isFPOrFPVectorTy to shorten code. NFC llvm-svn: 307491
* [IR] Rename BinaryOperator::init to AssertOK and remove argument. Replace ↵Craig Topper2017-06-261-6/+5
| | | | | | | | default case in switch with llvm_unreachable since all valid opcodes are covered. This method doesn't do any initializing. It just contains asserts. So renaming to AssertOK makes it consistent with similar instructions in other Instruction classes. llvm-svn: 306277
OpenPOWER on IntegriCloud