summaryrefslogtreecommitdiffstats
path: root/llvm/lib/IR/Verifier.cpp
Commit message (Collapse)AuthorAgeFilesLines
...
* Revert "Assert that we have all use/users in the getters."Michael Zolotukhin2016-01-141-3/+1
| | | | | | This reverts commit fdb838f3f8a8b6896bbbd5285555874eb3b748eb. llvm-svn: 257751
* Re-Revert r257105 (Verifier debug info changes)Keno Fischer2016-01-131-50/+14
| | | | | | | While I investigate some new buildbot failures. This was originally reapplied as r257550 and r257558. llvm-svn: 257563
* Use utostr rather than std::to_stringKeno Fischer2016-01-131-2/+2
| | | | | | | Looks like std::to_string is not available for Android. Hopefully this fixes the bot. llvm-svn: 257558
* Reapply r257105 "[Verifier] Check that debug values have proper size"Keno Fischer2016-01-131-14/+50
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The follow extra changes were made to test cases: Manually making the variable be the actual type instead of a pointer to avoid pointer-size differences in generic code: LLVM :: DebugInfo/Generic/2010-03-24-MemberFn.ll LLVM :: DebugInfo/Generic/2010-04-06-NestedFnDbgInfo.ll LLVM :: DebugInfo/Generic/2010-05-03-DisableFramePtr.ll LLVM :: DebugInfo/Generic/varargs.ll Delete sizing information from debug info for the same reason (but the presence of the pointer was important to the test case): LLVM :: DebugInfo/Generic/restrict.ll LLVM :: DebugInfo/Generic/tu-composite.ll LLVM :: Linker/type-unique-type-array-a.ll LLVM :: Linker/type-unique-simple2.ll Fixing an incorrect DW_OP_deref LLVM :: DebugInfo/Generic/2010-05-03-OriginDIE.ll Fixing a missing DW_OP_deref LLVM :: DebugInfo/Generic/incorrect-variable-debugloc.ll Additionally, clang should no longer complain during bootstrap should no longer happen after r257534. The original commit message was: ``` Summary: Teach the Verifier to make sure that the storage size given to llvm.dbg.declare or the value size given to llvm.dbg.value agree with what is declared in DebugInfo. This is implicitly assumed in a number of passes (e.g. in SROA). Additionally this catches a number of common mistakes, such as passing a pointer when a value was intended or vice versa. One complication comes from stack coloring which modifies the original IR when it merges allocas in order to make sure that if AA falls back to the IR it gets the correct result. However, given this new invariant, indiscriminately replacing one alloca by a different (differently sized one) is no longer valid. Fix this by just undefing out any use of the alloca in a dbg.declare in this case. Additionally, I had to fix a number of test cases. Of particular note: - I regenerated dbg-changes-codegen-branch-folding.ll from the given source as it was affected by the bug fixed in r256077 - two-cus-from-same-file.ll was changed to avoid having a variable-typed debug variable as that would depend on the target, even though this test is supposed to be generic - I had to manually declared size/align for reference type. See also the discussion for D14275/r253186. - fpstack-debuginstr-kill.ll required changing `double` to `long double` - most others were just a question of adding OP_deref ``` llvm-svn: 257550
* [WinEH] Fix catchpad pred verificationJoseph Tremoulet2016-01-101-0/+3
| | | | | | | | | | | | | | | Summary: The code was simply ensuring that the catchpad's pred is its catchswitch, which was letting cases slip through where the flow edge was the unwind edge of the catchswitch rather than one of its catch clauses. Reviewers: andrew.w.kaylor, rnk, majnemer Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D16011 llvm-svn: 257275
* [WinEH] Disallow cyclic unwindsJoseph Tremoulet2016-01-101-4/+78
| | | | | | | | | | | | | | | | Summary: Funclet-based EH personalities/tables likely can't handle these, and they can't be generated at source, so make them officially illegal in IR as well. Reviewers: andrew.w.kaylor, rnk, majnemer Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D15963 llvm-svn: 257274
* [WinEH] Verify consistent funclet unwind exitsJoseph Tremoulet2016-01-101-22/+146
| | | | | | | | | | | | | | | | | | | | Summary: A funclet EH pad may be exited by an unwind edge, which may be a cleanupret exiting its cleanuppad, an invoke exiting a funclet, or an unwind out of a nested funclet transitively exiting its parent. Funclet EH personalities require all such exceptional exits from a given funclet to have the same unwind destination, and EH preparation / state numbering / table generation implicitly depends on this. Formalize it as a rule of the IR in the LangRef and verifier. Reviewers: rnk, majnemer, andrew.w.kaylor Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D15962 llvm-svn: 257273
* [WinEH] Verify unwind edges against EH pad treeJoseph Tremoulet2016-01-101-3/+36
| | | | | | | | | | | | | | | | | | | | | | Summary: Funclet EH personalities require a tree-like nesting among funclets (enforced by the ParentPad linkage in the IR), and also require that unwind edges conform to certain rules with respect to the tree: - An unwind edge may exit 0 or more ancestor pads - An unwind edge must enter exactly one EH pad, which must be distinct from any exited pads - A cleanupret's edge must exit its cleanuppad Describe these rules in the LangRef, and enforce them in the verifier. Reviewers: rnk, majnemer, andrew.w.kaylor Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D15961 llvm-svn: 257272
* Temporarily revert r257105 "[Verifier] Check that debug values have proper size"Keno Fischer2016-01-071-50/+14
| | | | | | | Looks like there's a case where clang generates debug info that triggers the new verifier check. Reverting while investigating. llvm-svn: 257107
* [Verifier] Check that debug values have proper sizeKeno Fischer2016-01-071-14/+50
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: Teach the Verifier to make sure that the storage size given to llvm.dbg.declare or the value size given to llvm.dbg.value agree with what is declared in DebugInfo. This is implicitly assumed in a number of passes (e.g. in SROA). Additionally this catches a number of common mistakes, such as passing a pointer when a value was intended or vice versa. One complication comes from stack coloring which modifies the original IR when it merges allocas in order to make sure that if AA falls back to the IR it gets the correct result. However, given this new invariant, indiscriminately replacing one alloca by a different (differently sized one) is no longer valid. Fix this by just undefing out any use of the alloca in a dbg.declare in this case. Additionally, I had to fix a number of test cases. Of particular note: - I regenerated dbg-changes-codegen-branch-folding.ll from the given source as it was affected by the bug fixed in r256077 - two-cus-from-same-file.ll was changed to avoid having a variable-typed debug variable as that would depend on the target, even though this test is supposed to be generic - I had to manually declared size/align for reference type. See also the discussion for D14275/r253186. - fpstack-debuginstr-kill.ll required changing `double` to `long double` - most others were just a question of adding OP_deref Reviewers: aprantl Differential Revision: http://reviews.llvm.org/D14276 llvm-svn: 257105
* Added support for macro emission in dwarf (supporting DWARF version 4).Amjad Aboud2016-01-071-0/+3
| | | | | | Differential Revision: http://reviews.llvm.org/D15495 llvm-svn: 257060
* [Statepoints] Initial support for relocating vectors of pointersPhilip Reames2016-01-071-8/+14
| | | | | | | | | | | | Currently, we try to split vectors of pointers back into their component pointer elements during rewrite-statepoints-for-gc. This is less than ideal since presumably the vectorizer chose to vectorize for a reason. :) It's also been a source of bugs - in particular, the relocation logic as currently implemented was recently discovered to be wrong. The alternate approach is to allow gc.relocates of vector-of-pointer type and update the backend to handle them. That's what this patch tries to do. This won't actually enable vector-of-pointers in practice - there are some RS4GC changes needed - but the lowering is standalone and testable so it makes sense to separate. Note that there are some known cases around vector constants which this patch does not handle. Once this is in, I'll send another patch with individual fixes and test cases. Differential Revision: http://reviews.llvm.org/D15632 llvm-svn: 257022
* [Statepoints] Refactor GCRelocateOperands into an intrinsic wrapper. NFC.Manuel Jacob2016-01-051-7/+7
| | | | | | | | | | | | | | | Summary: This commit renames GCRelocateOperands to GCRelocateInst and makes it an intrinsic wrapper, similar to e.g. MemCpyInst. Also, all users of GCRelocateOperands were changed to use the new intrinsic wrapper instead. Reviewers: sanjoy, reames Subscribers: reames, sanjoy, llvm-commits Differential Revision: http://reviews.llvm.org/D15762 llvm-svn: 256811
* [Verifier] Add braces to satisfy buildbots. NFCJoseph Tremoulet2016-01-021-1/+2
| | | | | | Fix build break introduced by r256691. llvm-svn: 256692
* [WinEH] Verify catchswitch handlersJoseph Tremoulet2016-01-021-0/+7
| | | | | | | | | | | | | | Summary: The handler list must be nonempty and consist solely of CatchPads. Reviewers: rnk, andrew.w.kaylor, majnemer Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D15842 llvm-svn: 256691
* [WinEH] Tighten parentPad verifier checksJoseph Tremoulet2016-01-021-4/+2
| | | | | | | | | | | | Summary: A catchswitch cannot be a parent of a cleanuppad or another catchswitch. Reviewers: rnk, andrew.w.kaylor, majnemer Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D15841 llvm-svn: 256690
* [gc.statepoint] Change gc.statepoint intrinsic's return type to token type ↵Chen Li2015-12-261-7/+4
| | | | | | | | | | | | | | instead of i32 type Summary: This patch changes gc.statepoint intrinsic's return type to token type instead of i32 type. Using token types could prevent LLVM to merge different gc.statepoint nodes into PHI nodes and cause further problems with gc relocations. The patch also changes the way on how gc.relocate and gc.result look for their corresponding gc.statepoint on unwind path. The current implementation uses the selector value extracted from a { i8*, i32 } landingpad as a hook to find the gc.statepoint, while the patch directly uses a token type landingpad (http://reviews.llvm.org/D15405) to find the gc.statepoint. Reviewers: sanjoy, JosephTremoulet, pgavlin, igor-laevsky, mjacob Subscribers: reames, mjacob, sanjoy, llvm-commits Differential Revision: http://reviews.llvm.org/D15662 llvm-svn: 256443
* Remove deprecated llvm.experimental.gc.result.{int,float,ptr} intrinsics.Manuel Jacob2015-12-221-3/+0
| | | | | | | | | | | | | | Summary: These were deprecated 11 months ago when a generic llvm.experimental.gc.result intrinsic, which works for all types, was added. Reviewers: sanjoy, reames Subscribers: sanjoy, chenli, llvm-commits Differential Revision: http://reviews.llvm.org/D15719 llvm-svn: 256262
* Assert that we have all use/users in the getters.Rafael Espindola2015-12-191-1/+3
| | | | | | | | | | | | | | An error that is pretty easy to make is to use the lazy bitcode reader and then do something like if (V.use_empty()) The problem is that uses in unmaterialized functions are not accounted for. This patch adds asserts that all uses are known. llvm-svn: 256105
* Polish atomic pointersJF Bastien2015-12-171-25/+24
| | | | | | | | | | | | | | | | | | | | | | Summary: I didn't realize that we already allowed atomic load/store of pointers, it was added in 2012 by r162146. This patch updates the documentation and tightens the verifier by using DataLayout to make sure that the stored size is byte-sized and power-of-two. DataLayout is also used for integers, and while I'm here I updated the corresponding code for cmpxchg and rmw. See the following discussion for context and upcoming changes to add floating-point and vector atomics: https://groups.google.com/forum/#!topic/llvm-dev/Nh0P_E3CRoo/discussion Reviewers: reames Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D15512 llvm-svn: 255931
* Add InaccessibleMemOnly and inaccessibleMemOrArgMemOnly attributesVaivaswatha Nagaraj2015-12-161-1/+15
| | | | | | | | | | | | | | | | | | Summary: This patch introduces two new function attributes InaccessibleMemOnly: This attribute indicates that the function may only access memory that is not accessible by the program/IR being compiled. This is a weaker form of ReadNone. inaccessibleMemOrArgMemOnly: This attribute indicates that the function may only access memory that is either not accessible by the program/IR being compiled, or is pointed to by its pointer arguments. This is a weaker form of ArgMemOnly Test cases have been updated. This revision uses this (https://github.com/llvm-mirror/llvm/commit/d001932f3a8aa1ebd1555162fdce365f011bc292) as reference. Reviewers: jmolloy, hfinkel Subscribers: reames, joker.eph, llvm-commits Differential Revision: http://reviews.llvm.org/D15499 llvm-svn: 255778
* [IR] Add support for floating pointer atomic loads and storesPhilip Reames2015-12-161-3/+5
| | | | | | | | | | | | | | | | This patch allows atomic loads and stores of floating point to be specified in the IR and adds an adapter to allow them to be lowered via existing backend support for bitcast-to-equivalent-integer idiom. Previously, the only way to specify a atomic float operation was to bitcast the pointer to a i32, load the value as an i32, then bitcast to a float. At it's most basic, this patch simply moves this expansion step to the point we start lowering to the backend. This patch does not add canonicalization rules to convert the bitcast idioms to the appropriate atomic loads. I plan to do that in the future, but for now, let's simply add the support. I'd like to get instruction selection working through at least one backend (x86-64) without the bitcast conversion before canonicalizing into this form. Similarly, I haven't yet added the target hooks to opt out of the lowering step I added to AtomicExpand. I figured it would more sense to add those once at least one backend (x86) was ready to actually opt out. As you can see from the included tests, the generated code quality is not great. I plan on submitting some patches to fix this, but help from others along that line would be very welcome. I'm not super familiar with the backend and my ramp up time may be material. Differential Revision: http://reviews.llvm.org/D15471 llvm-svn: 255737
* [WinEH] Use operand bundles to describe call sitesDavid Majnemer2015-12-151-3/+17
| | | | | | | | | | | | | | | | | SimplifyCFG allows tail merging with code which terminates in unreachable which, in turn, makes it possible for an invoke to end up in a funclet which it was not originally part of. Using operand bundles on invokes allows us to determine whether or not an invoke was part of a funclet in the source program. Furthermore, it allows us to unambiguously answer questions about the legality of inlining into call sites which the personality may have trouble with. Differential Revision: http://reviews.llvm.org/D15517 llvm-svn: 255674
* [IR] Remove terminatepadDavid Majnemer2015-12-141-36/+2
| | | | | | | | | | | | | 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-85/+70
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Verifier: Avoid quadratic checking of aggregates for bad bitcastsDuncan P. N. Exon Smith2015-12-101-38/+37
| | | | | | | | | | | | | | | | | | | | | | | Avoid O(N^2) behaviour when checking for bad bitcasts in `ConstantExpr`s buried inside of aggregate initializers to `GlobalVariable`s. I've: - centralized the "visited" set for recursing through `ConstantExpr`s so that expressions are only visited once per Verifier run, - removed the duplicate logic for the stack visit, and - avoided recursing into other `GlobalValue`s. This recovers roughly a 100x time difference in clang compiles of a particular input file (filled with large cross-referencing tables) that depends on whether `-disable-llvm-verifier` is on. This slowdown was caused by r187506, which introduced these checks. Now, avoiding `-disable-llvm-verifier` only causes a 2x slowdown for this case. (Interestingly, dumping the textual IR for this file starts at least 50GB of global variable initializers (I don't know the total, since I killed the dump)...) llvm-svn: 255269
* Macro debug info support in LLVM IRAmjad Aboud2015-12-101-2/+27
| | | | | | | | Introduced DIMacro and DIMacroFile debug info metadata in the LLVM IR to support macros. Differential Revision: http://reviews.llvm.org/D14687 llvm-svn: 255245
* [Verifier] Fix !dbg validation if Scope is the SubprogramKeno Fischer2015-12-061-1/+4
| | | | | | | | | | | | | | | | | | Summary: We are inserting both Scope and SP into the Seen map and check whether it was already there in which case we skip the validation (the idea being that we already checked this Subprogram before). However, if (Scope == SP) as MDNodes, then inserting the Scope, will trigger the Seen check causing us to incorrectly not validate this !dbg attachment. Fix this by not performing the SP Seen check if Scope == SP Reviewers: pcc, dexonsmith, dblaikie Subscribers: dblaikie, llvm-commits Differential Revision: http://reviews.llvm.org/D14697 llvm-svn: 254887
* [Verifier] Improve error for cross-module refsKeno Fischer2015-12-011-3/+10
| | | | | | | | | | | | | | By including the module name in the error message. This makes the error message much more useful and saves a trip to the debugger. Reviewers: dexonsmith Subscribers: dexonsmith, llvm-commits Differential Revision: http://reviews.llvm.org/D14473 llvm-svn: 254437
* Disallow aliases to available_externally.Rafael Espindola2015-11-261-1/+2
| | | | | | | | | | | | They are as much trouble as aliases to declarations. They are requiring the code generator to define a symbol with the same value as another symbol, but the second symbol is undefined. If representing this is important for some optimization, we could add support for available_externally aliases. They would be *required* to point to a declaration (or available_externally definition). llvm-svn: 254170
* Revert "Change memcpy/memset/memmove to have dest and source alignments."Pete Cooper2015-11-191-1/+1
| | | | | | | | | | This reverts commit r253511. This likely broke the bots in http://lab.llvm.org:8011/builders/clang-ppc64-elf-linux2/builds/20202 http://bb.pgr.jp/builders/clang-3stage-i686-linux/builds/3787 llvm-svn: 253543
* Change memcpy/memset/memmove to have dest and source alignments.Pete Cooper2015-11-181-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Note, this was reviewed (and more details are in) http://lists.llvm.org/pipermail/llvm-commits/Week-of-Mon-20151109/312083.html These intrinsics currently have an explicit alignment argument which is required to be a constant integer. It represents the alignment of the source and dest, and so must be the minimum of those. This change allows source and dest to each have their own alignments by using the alignment attribute on their arguments. The alignment argument itself is removed. There are a few places in the code for which the code needs to be checked by an expert as to whether using only src/dest alignment is safe. For those places, they currently take the minimum of src/dest alignments which matches the current behaviour. For example, code which used to read: call void @llvm.memcpy.p0i8.p0i8.i32(i8* %dest, i8* %src, i32 500, i32 8, i1 false) will now read: call void @llvm.memcpy.p0i8.p0i8.i32(i8* align 8 %dest, i8* align 8 %src, i32 500, i1 false) For out of tree owners, I was able to strip alignment from calls using sed by replacing: (call.*llvm\.memset.*)i32\ [0-9]*\,\ i1 false\) with: $1i1 false) and similarly for memmove and memcpy. I then added back in alignment to test cases which needed it. A similar commit will be made to clang which actually has many differences in alignment as now IRBuilder can generate different source/dest alignments on calls. In IRBuilder itself, a new argument was added. Instead of calling: CreateMemCpy(Dst, Src, getInt64(Size), DstAlign, /* isVolatile */ false) you now call CreateMemCpy(Dst, Src, getInt64(Size), DstAlign, SrcAlign, /* isVolatile */ false) There is a temporary class (IntegerAlignment) which takes the source alignment and rejects implicit conversion from bool. This is to prevent isVolatile here from passing its default parameter to the source alignment. Note, changes in future can now be made to codegen. I didn't change anything here, but this change should enable better memcpy code sequences. Reviewed by Hal Finkel. llvm-svn: 253511
* Also map the personality function in CloneFunctionIntoKeno Fischer2015-11-161-0/+8
| | | | | | | | | | | | | | | | Summary: The Old personality function gets copied over, but the Materializer didn't have a chance to inspect it (e.g. to fix up references to the correct module for the target function). Also add a verifier check that makes sure the personality routine is in the same module as the function whose personality it is. Reviewers: majnemer Subscribers: jevinskie, llvm-commits Differential Revision: http://reviews.llvm.org/D14474 llvm-svn: 253183
* Introduce deoptimization operand bundlesSanjoy Das2015-11-111-0/+9
| | | | | | | | | | | | | | | | | | | | | Summary: This change introduces the notion of "deoptimization" operand bundles. LLVM can recognize and optimize these in more precise ways than it can a generic "unknown" operand bundles. The current form of this special recognition / optimization is an enum entry in LLVMContext, a LangRef blurb and a verifier rule. Over time we will teach LLVM to do more aggressive optimization around deoptimization operand bundles, exploiting known facts about kinds of state deoptimization operand bundles are allowed to track. Reviewers: reames, majnemer, chandlerc, dexonsmith Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D14551 llvm-svn: 252806
* Add a new attribute: norecurseJames Molloy2015-11-061-1/+2
| | | | | | This attribute allows the compiler to assume that the function never recurses into itself, either directly or indirectly (transitively). This can be used among other things to demote global variables to locals. llvm-svn: 252282
* DI: Reverse direction of subprogram -> function edge.Peter Collingbourne2015-11-051-42/+35
| | | | | | | | | | | | | | | | | | | | | | | Previously, subprograms contained a metadata reference to the function they described. Because most clients need to get or set a subprogram for a given function rather than the other way around, this created unneeded inefficiency. For example, many passes needed to call the function llvm::makeSubprogramMap() to build a mapping from functions to subprograms, and the IR linker needed to fix up function references in a way that caused quadratic complexity in the IR linking phase of LTO. This change reverses the direction of the edge by storing the subprogram as function-level metadata and removing DISubprogram's function field. Since this is an IR change, a bitcode upgrade has been provided. Fixes PR23367. An upgrade script for textual IR for out-of-tree clients is attached to the PR. Differential Revision: http://reviews.llvm.org/D14265 llvm-svn: 252219
* [Verifier] Minor comment update, NFCVedant Kumar2015-10-211-2/+1
| | | | llvm-svn: 250943
* Add verification for align, dereferenceable, dereferenceable_or_null load ↵Artur Pilipenko2015-10-091-0/+36
| | | | | | | | | | metadata Reviewed By: reames Differential Revision: http://reviews.llvm.org/D13428 llvm-svn: 249856
* IR: Remove implicit iterator conversions from lib/IR, NFCDuncan P. N. Exon Smith2015-10-081-0/+4
| | | | | | | | | | | | | | | | | | | | | | | | Stop converting implicitly between iterators and pointers/references in lib/IR. For convenience, I've added a `getIterator()` accessor to `ilist_node` so that callers don't need to know how to spell the iterator class (i.e., they can use `X.getIterator()` instead of `Function::iterator(X)`). I'll eventually disallow these implicit conversions entirely, but there's a lot of code, so it doesn't make sense to do it all in one patch. One library or so at a time. Why? To root out cases of `getNextNode()` and `getPrevNode()` being used in iterator logic. The design of `ilist` makes that invalid when the current node could be at the back of the list, but it happens to "work" right now because of a bug where those functions never return `nullptr` if you're using a half-node sentinel. Before I can fix the function, I have to remove uses of it that rely on it misbehaving. (Maybe the function should just be deleted anyway? But I don't want deleting it -- potentially a huge project -- to block fixing ilist/iplist.) llvm-svn: 249782
* [SEH] Add llvm.eh.exceptioncode intrinsicReid Kleckner2015-10-071-0/+1
| | | | | | This will support the Clang __exception_code intrinsic. llvm-svn: 249492
* [WinEH] Add llvm.eh.exceptionpointer intrinsicJoseph Tremoulet2015-09-031-0/+5
| | | | | | | | | | | | | | | | | Summary: This intrinsic can be used to extract a pointer to the exception caught by a given catchpad. Its argument has token type and must be a `catchpad`. Also clarify ExtendingLLVM documentation regarding overloaded intrinsics. Reviewers: majnemer, andrew.w.kaylor, sanjoy, rnk Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D12533 llvm-svn: 246752
* [WinEH] Add cleanupendpad instructionJoseph Tremoulet2015-09-031-9/+47
| | | | | | | | | | | | | | | | | | | | | | | 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
* [TableGen] Allow TokenTy in intrinsic signaturesJoseph Tremoulet2015-09-021-0/+1
| | | | | | | | | | | | | | | | | Summary: Add the necessary plumbing so that llvm_token_ty can be used as an argument/return type in intrinsic definitions and correspondingly require TokenTy in function types. TokenTy is an opaque type that has no target lowering, but can be used in machine-independent intrinsics. It is required for the upcoming llvm.eh.padparam intrinsic. Reviewers: majnemer, rnk Subscribers: stoklund, llvm-commits Differential Revision: http://reviews.llvm.org/D12532 llvm-svn: 246651
* DI: Add Function::getSubprogram()Duncan P. N. Exon Smith2015-08-281-1/+13
| | | | | | | | | | | | | | | | | | Add `Function::setSubprogram()` and `Function::getSubprogram()`, convenience methods to forward to `setMetadata()` and `getMetadata()`, respectively, and deal in `DISubprogram` instead of `MDNode`. Also add a verifier check to enforce that `!dbg` attachments are always subprograms. Originally (when I had the llvm-dev discussion back in April) I thought I'd store a pointer directly on `llvm::Function` for these attachments -- we frequently have debug info, and that's much cheaper than using map in the context if there are no other function-level attachments -- but for now I'm just using the generic infrastructure. Let's add the extra complexity only if this shows up in a profile. llvm-svn: 246339
* DI: Require subprogram definitions to be distinctDuncan P. N. Exon Smith2015-08-281-0/+3
| | | | | | | | | | | | | | | | | | | | | | | | As a follow-up to r246098, require `DISubprogram` definitions (`isDefinition: true`) to be 'distinct'. Specifically, add an assembler check, a verifier check, and bitcode upgrading logic to combat testcase bitrot after the `DIBuilder` change. While working on the testcases, I realized that test/Linker/subprogram-linkonce-weak-odr.ll isn't relevant anymore. Its purpose was to check for a corner case in PR22792 where two subprogram definitions match exactly and share the same metadata node. The new verifier check, requiring that subprogram definitions are 'distinct', precludes that possibility. I updated almost all the IR with the following script: git grep -l -E -e '= !DISubprogram\(.* isDefinition: true' | grep -v test/Bitcode | xargs sed -i '' -e 's/= \(!DISubprogram(.*, isDefinition: true\)/= distinct \1/' Likely some variant of would work for out-of-tree testcases. llvm-svn: 246327
* [WinEH] Require token linkage in EH pad/ret signaturesJoseph Tremoulet2015-08-231-26/+21
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Verifier: Don't crash on null entries in debug info retained types listDavid Blaikie2015-08-221-1/+1
| | | | | | | | There was already a good error path for this. Added a test for it & made a minor code change to ensure the error path was actually reached, rather than crashing before we got that far. llvm-svn: 245795
* [IR] Add token typesDavid Majnemer2015-08-141-4/+21
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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] Verify EH pad predecessorsDavid Majnemer2015-08-111-14/+51
| | | | | | | Make sure that an EH pad's predecessors are using their unwind edge to transfer control to the EH pad. llvm-svn: 244563
* DI: Disallow uniquable DICompileUnitsDuncan P. N. Exon Smith2015-08-031-0/+1
| | | | | | | | | | | | | | | | | | Since r241097, `DIBuilder` has only created distinct `DICompileUnit`s. The backend is liable to start relying on that (if it hasn't already), so make uniquable `DICompileUnit`s illegal and automatically upgrade old bitcode. This is a nice cleanup, since we can remove an unnecessary `DenseSet` (and the associated uniquing info) from `LLVMContextImpl`. Almost all the testcases were updated with this script: git grep -e '= !DICompileUnit' -l -- test | grep -v test/Bitcode | xargs sed -i '' -e 's,= !DICompileUnit,= distinct !DICompileUnit,' I imagine something similar should work for out-of-tree testcases. llvm-svn: 243885
OpenPOWER on IntegriCloud