summaryrefslogtreecommitdiffstats
path: root/llvm/lib/IR/Instructions.cpp
Commit message (Collapse)AuthorAgeFilesLines
* use 'auto' with 'dyn_cast' and fix formatting; NFCSanjay Patel2017-04-191-8/+7
| | | | llvm-svn: 300713
* [IR] Make paramHasAttr to use arg indices instead of attr indicesReid Kleckner2017-04-141-8/+32
| | | | | | | | | This avoids the confusing 'CS.paramHasAttr(ArgNo + 1, Foo)' pattern. Previously we were testing return value attributes with index 0, so I introduced hasReturnAttr() for that use case. llvm-svn: 300367
* [IR] Redesign the case iterator in SwitchInst to actually be an iteratorChandler Carruth2017-04-121-4/+4
| | | | | | | | | | | | | | | | and to expose a handle to represent the actual case rather than having the iterator return a reference to itself. All of this allows the iterator to be used with common STL facilities, standard algorithms, etc. Doing this exposed some missing facilities in the iterator facade that I've fixed and required some work to the actual iterator to fully support the necessary API. Differential Revision: https://reviews.llvm.org/D31548 llvm-svn: 300032
* Module::getOrInsertFunction is using C-style vararg instead of variadic ↵Serge Guelton2017-04-111-2/+2
| | | | | | | | | | | templates. From a user prospective, it forces the use of an annoying nullptr to mark the end of the vararg, and there's not type checking on the arguments. The variadic template is an obvious solution to both issues. Differential Revision: https://reviews.llvm.org/D31070 llvm-svn: 299949
* Revert "Turn some C-style vararg into variadic templates"Diana Picus2017-04-111-2/+2
| | | | | | | This reverts commit r299925 because it broke the buildbots. See e.g. http://lab.llvm.org:8011/builders/clang-cmake-armv7-a15/builds/6008 llvm-svn: 299928
* Turn some C-style vararg into variadic templatesSerge Guelton2017-04-111-2/+2
| | | | | | | | | | | | Module::getOrInsertFunction is using C-style vararg instead of variadic templates. From a user prospective, it forces the use of an annoying nullptr to mark the end of the vararg, and there's not type checking on the arguments. The variadic template is an obvious solution to both issues. llvm-svn: 299925
* Allow DataLayout to specify addrspace for allocas.Matt Arsenault2017-04-101-18/+23
| | | | | | | | | | | | | | | | | | | | | | | LLVM makes several assumptions about address space 0. However, alloca is presently constrained to always return this address space. There's no real way to avoid using alloca, so without this there is no way to opt out of these assumptions. The problematic assumptions include: - That the pointer size used for the stack is the same size as the code size pointer, which is also the maximum sized pointer. - That 0 is an invalid, non-dereferencable pointer value. These are problems for AMDGPU because alloca is used to implement the private address space, which uses a 32-bit index as the pointer value. Other pointers are 64-bit and behave more like LLVM's notion of generic address space. By changing the address space used for allocas, we can change our generic pointer type to be LLVM's generic pointer type which does have similar properties. llvm-svn: 299888
* Revert "Turn some C-style vararg into variadic templates"Mehdi Amini2017-04-061-2/+2
| | | | | | This reverts commit r299699, the examples needs to be updated. llvm-svn: 299702
* Turn some C-style vararg into variadic templatesMehdi Amini2017-04-061-2/+2
| | | | | | | | | | | | | | | | Module::getOrInsertFunction is using C-style vararg instead of variadic templates. From a user prospective, it forces the use of an annoying nullptr to mark the end of the vararg, and there's not type checking on the arguments. The variadic template is an obvious solution to both issues. Patch by: Serge Guelton <serge.guelton@telecom-bretagne.eu> Differential Revision: https://reviews.llvm.org/D31070 llvm-svn: 299699
* [IR] Make SwitchInst::CaseIt almost a normal iterator.Chandler Carruth2017-03-261-1/+3
| | | | | | | | | | | | | | | | | | | | | | | | | This moves it to the iterator facade utilities giving it full random access semantics, etc. It can also now be used with standard algorithms like std::all_of and std::any_of and range adaptors like llvm::reverse. Also make the semantics of iterating match what every other iterator uses and forbid decrementing past the begin iterator. This was used as a hacky way to work around iterator invalidation. However, every instance trying to do this failed to actually avoid touching invalid iterators despite the clear documentation that the removed and all subsequent iterators become invalid including the end iterator. So I've added a return of the next iterator to removeCase and rewritten the loops that were doing this to correctly follow the iterator pattern of either incremneting or removing and assigning fresh values to the iterator and the end. In one case we were trying to go backwards to make this cleaner but it doesn't actually work. I've made that code match the code we use everywhere else to remove cases as we iterate. This changes the order of cases in one test output and I moved that test to CHECK-DAG so it wouldn't care -- the order isn't semantically meaningful anyways. llvm-svn: 298791
* Rename AttributeSet to AttributeListReid Kleckner2017-03-211-18/+18
| | | | | | | | | | | | | | | | | | | | | | | | | Summary: This class is a list of AttributeSetNodes corresponding the function prototype of a call or function declaration. This class used to be called ParamAttrListPtr, then AttrListPtr, then AttributeSet. It is typically accessed by parameter and return value index, so "AttributeList" seems like a more intuitive name. Rename AttributeSetImpl to AttributeListImpl to follow suit. It's useful to rename this class so that we can rename AttributeSetNode to AttributeSet later. AttributeSet is the set of attributes that apply to a single function, argument, or return value. Reviewers: sanjoy, javed.absar, chandlerc, pete Reviewed By: pete Subscribers: pete, jholewinski, arsenm, dschuff, mehdi_amini, jfb, nhaehnle, sbc100, void, llvm-commits Differential Revision: https://reviews.llvm.org/D31102 llvm-svn: 298393
* fix comment formatting; NFCSanjay Patel2016-11-161-8/+4
| | | | llvm-svn: 287127
* IR: Change the Type::get{Array,Vector,Pointer}ElementType() functions to ↵Peter Collingbourne2016-11-131-1/+2
| | | | | | | | perform the correct type assertion. Previously we were only asserting that the type was a sequential type. llvm-svn: 286749
* Remove duplicated code; NFCSanjoy Das2016-10-021-63/+0
| | | | | | | ICmpInst::makeConstantRange does exactly the same thing as ConstantRange::makeExactICmpRegion. llvm-svn: 283059
* Rationalise the attribute getter/setter methods on Function and CallSite.Amaury Sechet2016-09-091-40/+0
| | | | | | | | | | | | | | | | | | | Summary: While woring on mapping attributes in the C API, it clearly appeared that the recent changes in the API on the C++ side left Function and Call/Invoke with an attribute API that grew in an ad hoc manner. This makes it difficult to work with it, because one doesn't know which overloads exists and which do not. Make sure that getter/setter function exists for both enum and string version. Remove inconsistent getter/setter, unless they have many callsites. This should make it easier to work with attributes in the future. This doesn't change how attribute works. Reviewers: bkramer, whitequark, mehdi_amini, void Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D21514 llvm-svn: 281019
* fix documentation comments; NFCSanjay Patel2016-09-021-5/+0
| | | | llvm-svn: 280489
* [Profile] refactor meta data copying/swapping codeXinliang David Li2016-08-231-9/+1
| | | | | | Differential Revision: http://reviews.llvm.org/D23619 llvm-svn: 279523
* GlobalISel: support irtranslation of icmp instructions.Tim Northover2016-08-171-0/+32
| | | | llvm-svn: 278969
* Add getReturnedArgOperand to Call/InvokeInst, CallSiteHal Finkel2016-07-101-0/+26
| | | | | | | | | | | | | | | In order to make the optimizer smarter about using the 'returned' argument attribute (generally, but motivated by my llvm.noalias intrinsic work), add a utility function to Call/InvokeInst, and CallSite, to make it easy to get the returned call argument (when one exists). P.S. There is already an unfortunate amount of code duplication between CallInst and InvokeInst, and this adds to it. We should probably clean that up separately. Differential Revision: http://reviews.llvm.org/D22204 llvm-svn: 275031
* Add support for string attributes in the C API.Amaury Sechet2016-06-151-0/+20
| | | | | | | | | | | | Summary: As per title. This completes the C API Attribute support. Reviewers: Wallbraker, whitequark, echristo, rafael, jyknight Subscribers: mehdi_amini Differential Revision: http://reviews.llvm.org/D21365 llvm-svn: 272811
* Add support for callsite in the new C API for attributesAmaury Sechet2016-06-151-0/+21
| | | | | | | | | | | | Summary: The second consumer of attributes. Reviewers: Wallbraker, whitequark, echristo, rafael, jyknight Subscribers: mehdi_amini Differential Revision: http://reviews.llvm.org/D21266 llvm-svn: 272754
* Make sure attribute kind and attributes are named respectively Kind and Attr ↵Amaury Sechet2016-06-141-25/+24
| | | | | | consistently. Historically they used to be the same the terminology is very confused in the codebase. NFC. llvm-svn: 272704
* [GlobalOpt] Propagate operand bundlesDavid Majnemer2016-04-291-12/+46
| | | | | | | We neglected to transfer operand bundles for some transforms. These were found via inspection, I'll try to come up with some test cases. llvm-svn: 268011
* [CodeGenPrepare] use branch weight metadata to decide if a select should be ↵Sanjay Patel2016-04-261-22/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | turned into a branch This is part of solving PR27344: https://llvm.org/bugs/show_bug.cgi?id=27344 CGP should undo the SimplifyCFG transform for the same reason that earlier patches have used this same mechanism: it's possible that passes between SimplifyCFG and CGP may be able to optimize the IR further with a select in place. For the TLI hook default, >99% taken or not taken is chosen as the default threshold for a highly predictable branch. Even the most limited HW branch predictors will be correct on this branch almost all the time, so even a massive mispredict penalty perf loss would be overcome by the win from all the times the branch was predicted correctly. As a follow-up, we could make the default target hook less conservative by using the SchedMachineModel's MispredictPenalty. Or we could just let targets override the default by implementing the hook with that and other target-specific options. Note that trying to statically determine mispredict rates for close-to-balanced profile weight data is generally impossible if the HW is sufficiently advanced. Ie, 50/50 taken/not-taken might still be 100% predictable. Finally, note that this patch as-is will not solve PR27344 because the current __builtin_unpredictable() branch weight default values are 4 and 64. A proposal to change that is in D19435. Differential Revision: http://reviews.llvm.org/D19488 llvm-svn: 267572
* Add check for "branch_weights" with prof metadataSanjay Patel2016-04-251-3/+7
| | | | | | | While we're here, fix the comment and variable names to make it clear that these are raw weights, not percentages. llvm-svn: 267491
* Typo. NFC.Chad Rosier2016-04-251-1/+1
| | | | llvm-svn: 267399
* replace duplicated static functions for profile metadata access with ↵Sanjay Patel2016-04-231-0/+18
| | | | | | BranchInst member function; NFCI llvm-svn: 267295
* [SimplifyCFG] Add final missing implications to isImpliedTrueByMatchingCmp.Chad Rosier2016-04-221-32/+5
| | | | | | | | | Summary: eq imply [u|s]ge and [u|s]le are true. Remove redundant logic by implementing isImpliedFalseByMatchingCmp(Pred1, Pred2) as isImpliedTrueByMatchingCmp(Pred1, getInversePredicate(Pred2)). llvm-svn: 267177
* [SimplifyCFG] Add missing implications to isImpliedTrueByMatchingCmp.Chad Rosier2016-04-221-5/+8
| | | | | | | | | Summary: [u|s]gt and [u|s]lt imply [u|s]ge and [u|s]le are true, respectively. I've simplified the existing tests and added additional tests to cover the new cases mentioned above. I've also added tests for all the cases where the first compare doesn't imply anything about the second compare. llvm-svn: 267171
* [EarlyCSE] Take the intersection of flags on instructionsDavid Majnemer2016-04-221-56/+0
| | | | | | | | | | | | | EarlyCSE had inconsistent behavior with regards to flag'd instructions: - In some cases, it would pessimize if the available instruction had different flags by not performing CSE. - In other cases, it would miscompile if it replaced an instruction which had no flags with an instruction which has flags. Fix this by being more consistent with our flag handling by utilizing andIRFlags. llvm-svn: 267111
* Add utility function to manipulate attributes on CallSite. NFCAmaury Sechet2016-04-211-0/+12
| | | | | | | | | | | | Summary: As per title. This will help work on the C API. Reviewers: Wallbraker, whitequark, joker.eph, echristo, rafael Subscribers: joker.eph, llvm-commits Differential Revision: http://reviews.llvm.org/D19173 llvm-svn: 267057
* Address Philip's post-commit feedback for r266987. NFC.Chad Rosier2016-04-211-2/+2
| | | | llvm-svn: 266998
* Refactor implied condition logic from ValueTracking directly into CmpInst. NFC.Chad Rosier2016-04-211-0/+52
| | | | | | Differential Revision: http://reviews.llvm.org/D19330 llvm-svn: 266987
* [DivergenceAnalysis] Treat PHI with incoming undef as constantNicolai Haehnle2016-04-141-0/+18
| | | | | | | | | | | | | | | | | | | | | | | Summary: If a PHI has an incoming undef, we can pretend that it is equal to one non-undef, non-self incoming value. This is particularly relevant in combination with the StructurizeCFG pass, which introduces PHI nodes with undefs. Previously, this lead to branch conditions that were uniform before StructurizeCFG to become non-uniform afterwards, which confused the SIAnnotateControlFlow pass. This fixes a crash when Mesa radeonsi compiles a shader from dEQP-GLES3.functional.shaders.switch.switch_in_for_loop_dynamic_vertex Reviewers: arsenm, tstellarAMD, jingyue Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D19013 llvm-svn: 266347
* NFC: make AtomicOrdering an enum classJF Bastien2016-04-061-18/+20
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: In the context of http://wg21.link/lwg2445 C++ uses the concept of 'stronger' ordering but doesn't define it properly. This should be fixed in C++17 barring a small question that's still open. The code currently plays fast and loose with the AtomicOrdering enum. Using an enum class is one step towards tightening things. I later also want to tighten related enums, such as clang's AtomicOrderingKind (which should be shared with LLVM as a 'C++ ABI' enum). This change touches a few lines of code which can be improved later, I'd like to keep it as NFC for now as it's already quite complex. I have related changes for clang. As a follow-up I'll add: bool operator<(AtomicOrdering, AtomicOrdering) = delete; bool operator>(AtomicOrdering, AtomicOrdering) = delete; bool operator<=(AtomicOrdering, AtomicOrdering) = delete; bool operator>=(AtomicOrdering, AtomicOrdering) = delete; This is separate so that clang and LLVM changes don't need to be in sync. Reviewers: jyknight, reames Subscribers: jyknight, llvm-commits Differential Revision: http://reviews.llvm.org/D18775 llvm-svn: 265602
* Swift Calling Convention: add swifterror attribute.Manman Ren2016-04-011-0/+1
| | | | | | | | | | | | A ``swifterror`` attribute can be applied to a function parameter or an AllocaInst. This commit does not include any target-specific change. The target-specific optimization will come as a follow-up patch. Differential Revision: http://reviews.llvm.org/D18092 llvm-svn: 265189
* Fix pointers to go on the right hand side. NFC.Ana Pazos2016-02-031-15/+15
| | | | | | | | | | | | | Summary: Fixed pointers to go on the right hand side following coding guidelines. NFC. Patch by Mandeep Singh Grang. Reviewers: majnemer, arsenm, sanjoy Differential Revision: http://reviews.llvm.org/D16866 llvm-svn: 259703
* [OperandBundles] Copy DebugLoc with calls/invokesJoseph Tremoulet2016-01-141-0/+2
| | | | | | | | | | | | | | | | | Summary: The overloads of CallInst::Create and InvokeInst::Create that are used to adjust operand bundles purport to create a new instruction "identical in every way except [for] the operand bundles", so copy the DebugLoc along with everything else. Reviewers: sanjoy, majnemer Subscribers: majnemer, dblaikie, llvm-commits Differential Revision: http://reviews.llvm.org/D16157 llvm-svn: 257745
* Add function for testing string attributes to InvokeInst and CallSite. NFC.Manuel Jacob2016-01-051-14/+0
| | | | llvm-svn: 256856
* [WinEH] Simplify unreachable catchpadsJoseph Tremoulet2016-01-051-0/+11
| | | | | | | | | | | | | | | | Summary: At least for CoreCLR, a catchpad which immediately executes an `unreachable` instruction indicates that the exception can never have a matching type, and so such catchpads can be removed, and so can their catchswitches if the catchswitch becomes empty. Reviewers: rnk, andrew.w.kaylor, majnemer Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D15846 llvm-svn: 256809
* Use CmpInst::Predicate instead of 'unsigned short' in some places. NFCCraig Topper2015-12-151-15/+12
| | | | llvm-svn: 255623
* Add missing vtable anchor's.Pete Cooper2015-12-141-0/+6
| | | | | | | | | | | | | | The following description is from http://reviews.llvm.org/D15481: ICmpInst, GetElementPtrInst and PHINode have no anchor functions. This causes the vtable and the type info (if RTTI is enabled in user code) to be emitted in multiple translation units. Before 3.7, the destructors were the key functions for these nodes, but they have been removed. There have been discussions about this here: http://lists.llvm.org/pipermail/llvm-dev/2015-August/089010.html and here: http://lists.llvm.org/pipermail/llvm-dev/2015-December/092921.html. Patch by Visoiu Mistrih Francis llvm-svn: 255538
* [IR] Remove terminatepadDavid Majnemer2015-12-141-58/+0
| | | | | | | | | | | | | It turns out that terminatepad gives little benefit over a cleanuppad which calls the termination function. This is not sufficient to implement fully generic filters but MSVC doesn't support them which makes terminatepad a little over-designed. Depends on D15478. Differential Revision: http://reviews.llvm.org/D15479 llvm-svn: 255522
* [IR] Reformulate LLVM's EH funclet IRDavid Majnemer2015-12-121-210/+137
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | While we have successfully implemented a funclet-oriented EH scheme on top of LLVM IR, our scheme has some notable deficiencies: - catchendpad and cleanupendpad are necessary in the current design but they are difficult to explain to others, even to seasoned LLVM experts. - catchendpad and cleanupendpad are optimization barriers. They cannot be split and force all potentially throwing call-sites to be invokes. This has a noticable effect on the quality of our code generation. - catchpad, while similar in some aspects to invoke, is fairly awkward. It is unsplittable, starts a funclet, and has control flow to other funclets. - The nesting relationship between funclets is currently a property of control flow edges. Because of this, we are forced to carefully analyze the flow graph to see if there might potentially exist illegal nesting among funclets. While we have logic to clone funclets when they are illegally nested, it would be nicer if we had a representation which forbade them upfront. Let's clean this up a bit by doing the following: - Instead, make catchpad more like cleanuppad and landingpad: no control flow, just a bunch of simple operands; catchpad would be splittable. - Introduce catchswitch, a control flow instruction designed to model the constraints of funclet oriented EH. - Make funclet scoping explicit by having funclet instructions consume the token produced by the funclet which contains them. - Remove catchendpad and cleanupendpad. Their presence can be inferred implicitly using coloring information. N.B. The state numbering code for the CLR has been updated but the veracity of it's output cannot be spoken for. An expert should take a look to make sure the results are reasonable. Reviewers: rnk, JosephTremoulet, andrew.w.kaylor Differential Revision: http://reviews.llvm.org/D15139 llvm-svn: 255422
* [InstCombine] allow any pair of bitcasts to be combinedSanjay Patel2015-12-121-10/+12
| | | | | | | | | | | | | | | | | | | | This change is discussed in D15392 and should allow us to effectively revert: http://llvm.org/viewvc/llvm-project?view=revision&revision=255261 if we canonicalize bitcasts ahead of extracts. It should be safe to convert any pair of bitcasts into a single bitcast, however, it was mentioned here: http://lists.llvm.org/pipermail/llvm-commits/Week-of-Mon-20110829/127089.html that we're not allowed to bitcast from an x86_mmx to some other types, but I'm not seeing any failures from that, and we have regression tests in CodeGen/X86 that appear to cover all of those cases. Some day we'll get to remove that MMX wart from LLVM IR completely? Differential Revision: http://reviews.llvm.org/D15468 llvm-svn: 255399
* fix typos; NFCSanjay Patel2015-12-111-3/+3
| | | | llvm-svn: 255352
* Add arg_begin() and arg_end() to CallInst and InvokeInst; NFCISanjoy Das2015-12-101-4/+2
| | | | | | | | | | - This simplifies the CallSite class, arg_begin / arg_end are now simple wrapper getters. - In several places, we were creating CallSite instances solely to call arg_begin and arg_end. With this change, that's no longer required. llvm-svn: 255226
* Don't drop attributes when inlining through "deopt" operand bundlesSanjoy Das2015-12-091-0/+2
| | | | | | | Test case attached (test case also checks that we don't drop the calling convention, but that functionality was correct before this patch). llvm-svn: 255088
* [OperandBundles] Allow operand-specific attributes in operand bundlesSanjoy Das2015-12-041-2/+2
| | | | | | | | | | | | | Currently `OperandBundleUse::operandsHaveAttr` computes its result without being given a specific operand. This is problematic because it forces us to say that, e.g., even non-pointer operands in `"deopt"` operand bundles are `readonly`, which doesn't make sense. This commit changes `operandsHaveAttr` to work in the context of a specific operand, so that we can give the operand attributes that make sense for the operands's `llvm::Type`. llvm-svn: 254764
* Teach the inliner to track deoptimization stateSanjoy Das2015-11-181-0/+26
| | | | | | | | | | | | | | | | Summary: This change teaches LLVM's inliner to track and suitably adjust deoptimization state (tracked via deoptimization operand bundles) as it inlines through call sites. The operation is described in more detail in the LangRef changes. Reviewers: reames, majnemer, chandlerc, dexonsmith Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D14552 llvm-svn: 253438
OpenPOWER on IntegriCloud