summaryrefslogtreecommitdiffstats
path: root/llvm/lib/IR/Instructions.cpp
Commit message (Collapse)AuthorAgeFilesLines
...
* 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
* [IR] Make {Call,Invoke}::cloneImpl aware of operand bundlesSanjoy Das2015-11-101-0/+8
| | | | | | | | | This was an omission in the patch that landed initial support for operand bundles. So far we haven't hit this, but we will once the inliner is able to inline calls to functions that contain calls with operand bundles. llvm-svn: 252645
* [IR] Add bounds checking to dataOperandHasImpliedAttrSanjoy Das2015-11-051-0/+8
| | | | | | This is similar to the bounds check added to paramHasAttr in r252073. llvm-svn: 252130
* [IR] Add a `data_operand` abstractionSanjoy Das2015-11-041-0/+29
| | | | | | | | | | | | | | | | | | | | | Summary: Data operands of a call or invoke consist of the call arguments, and the bundle operands associated with the `call` (or `invoke`) instruction. The motivation for this change is that we'd like to be able to query "argument attributes" like `readonly` and `nocapture` for bundle operands naturally. This change also provides a conservative "implementation" for these attributes for any bundle operand, and an extension point for future work. Reviewers: chandlerc, majnemer, reames Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D14305 llvm-svn: 252077
* [IR] Add bounds checking to paramHasAttrSanjoy Das2015-11-041-0/+4
| | | | | | | | | | | | | | | | | Summary: This is intended to make a later change simpler. Note: adding this bounds checking required fixing `X86FastISel`. As far I can tell I've preserved original behavior but a careful review will be appreciated. Reviewers: reames Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D14304 llvm-svn: 252073
* [SCEV] Opportunistically interpret unsigned constraints as signedSanjoy Das2015-10-221-0/+17
| | | | | | | | | | | | | | | Summary: An unsigned comparision is equivalent to is corresponding signed version if both the operands being compared are positive. Teach SCEV to use this fact when profitable. Reviewers: atrick, hfinkel, reames, nlewycky Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D13687 llvm-svn: 251051
* [OperandBundles] Make function attributes conservatively correctSanjoy Das2015-10-221-0/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: This makes attribute accessors on `CallInst` and `InvokeInst` do the (conservatively) right thing. This essentially involves, in some cases, *not* falling back querying the attributes on the called `llvm::Function` when operand bundles are present. Attributes locally present on the `CallInst` or `InvokeInst` will still override operand bundle semantics. The LangRef has been amended to reflect this. Note: this change does not do anything prevent `-function-attrs` from inferring `CallSite` local attributes after inspecting the called function -- that will be done as a separate change. I've used `-adce` and `-early-cse` to test these changes. There is nothing special about these passes (and they did not require any changes) except that they seemed be the easiest way to write the tests. This change does not add deal with `argmemonly`. That's a later change because alias analysis requires a related fix before `argmemonly` can be tested. Reviewers: reames, chandlerc Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D13961 llvm-svn: 250973
* [IR] Add operand bundles to CallInst and InvokeInst.Sanjoy Das2015-09-241-4/+21
| | | | | | | | | | | | | | | | | | | | | | | | | Summary: This change teaches `CallInst`s and `InvokeInst`s to maintain a set of operand bundles as part of its operands. `CallInst`s and `InvokeInst`s with operand bundles co-allocate some space before their `Use` array to hold meta information about which of its operands are part of an operand bundle. The strings corresponding to the bundle tags are interned into `LLVMContextImpl::BundleTagCache` This change does not include any parsing / bitcode support. That's the next change. Depends on D12455. Reviewers: reames, chandlerc, majnemer, dexonsmith, kmod, JosephTremoulet, rnk, bogner Subscribers: MatzeB, sanjoy, llvm-commits Differential Revision: http://reviews.llvm.org/D12456 llvm-svn: 248527
* [WinEH] Add cleanupendpad instructionJoseph Tremoulet2015-09-031-0/+59
| | | | | | | | | | | | | | | | | | | | | | | Summary: Add a `cleanupendpad` instruction, used to mark exceptional exits out of cleanups (for languages/targets that can abort a cleanup with another exception). The `cleanupendpad` instruction is similar to the `catchendpad` instruction in that it is an EH pad which is the target of unwind edges in the handler and which itself has an unwind edge to the next EH action. The `cleanupendpad` instruction, similar to `cleanupret` has a `cleanuppad` argument indicating which cleanup it exits. The unwind successors of a `cleanuppad`'s `cleanupendpad`s must agree with each other and with its `cleanupret`s. Update WinEHPrepare (and docs/tests) to accomodate `cleanupendpad`. Reviewers: rnk, andrew.w.kaylor, majnemer Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D12433 llvm-svn: 246751
* [IR] Cleanup EH instructions a little bitDavid Majnemer2015-08-231-8/+2
| | | | | | Just a cosmetic change, no functionality change is intended. llvm-svn: 245818
* [WinEH] Require token linkage in EH pad/ret signaturesJoseph Tremoulet2015-08-231-60/+42
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: WinEHPrepare is going to require that cleanuppad and catchpad produce values of token type which are consumed by any cleanupret or catchret exiting the pad. This change updates the signatures of those operators to require/enforce that the type produced by the pads is token type and that the rets have an appropriate argument. The catchpad argument of a `CatchReturnInst` must be a `CatchPadInst` (and similarly for `CleanupReturnInst`/`CleanupPadInst`). To accommodate that restriction, this change adds a notion of an operator constraint to both LLParser and BitcodeReader, allowing appropriate sentinels to be constructed for forward references and appropriate error messages to be emitted for illegal inputs. Also add a verifier rule (noted in LangRef) that a catchpad with a catchpad predecessor must have no other predecessors; this ensures that WinEHPrepare will see the expected linear relationship between sibling catches on the same try. Lastly, remove some superfluous/vestigial casts from instruction operand setters operating on BasicBlocks. Reviewers: rnk, majnemer Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D12108 llvm-svn: 245797
* [IR] Give catchret an optional 'return value' operandDavid Majnemer2015-08-151-10/+21
| | | | | | | | | | | Some personality routines require funclet exit points to be clearly marked, this is done by producing a token at the funclet pad and consuming it at the corresponding ret instruction. CleanupReturnInst already had a spot for this operand but CatchReturnInst did not. Other personality routines don't need to use this which is why it has been made optional. llvm-svn: 245149
* [IR] Add token typesDavid Majnemer2015-08-141-1/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This introduces the basic functionality to support "token types". The motivation stems from the need to perform operations on a Value whose provenance cannot be obscured. There are several applications for such a type but my immediate motivation stems from WinEH. Our personality routine enforces a single-entry - single-exit regime for cleanups. After several rounds of optimizations, we may be left with a terminator whose "cleanup-entry block" is not entirely clear because control flow has merged two cleanups together. We have experimented with using labels as operands inside of instructions which are not terminators to indicate where we came from but found that LLVM does not expect such exotic uses of BasicBlocks. Instead, we can use this new type to clearly associate the "entry point" and "exit point" of our cleanup. This is done by having the cleanuppad yield a Token and consuming it at the cleanupret. The token type makes it impossible to obscure or otherwise hide the Value, making it trivial to track the relationship between the two points. What is the burden to the optimizer? Well, it turns out we have already paid down this cost by accepting that there are certain calls that we are not permitted to duplicate, optimizations have to watch out for such instructions anyway. There are additional places in the optimizer that we will probably have to update but early examination has given me the impression that this will not be heroic. Differential Revision: http://reviews.llvm.org/D11861 llvm-svn: 245029
* [IR] Cleanup indentation of EH instructionsDavid Majnemer2015-08-131-17/+15
| | | | | | No functional change is intended, just tidying up whitespace. llvm-svn: 244966
* [IR] Remove TerminateInst's "NameStr" argumentDavid Majnemer2015-08-061-11/+7
| | | | | | | TerminateInst can't have a name because it doesn't produce a result. No functionality change is intended, this is just a cleanup. llvm-svn: 244276
OpenPOWER on IntegriCloud