summaryrefslogtreecommitdiffstats
path: root/llvm/test/Assembler
Commit message (Collapse)AuthorAgeFilesLines
* DebugInfo: Add flag to CU to disable emission of inline debug info into the ↵David Blaikie2016-08-241-3/+3
| | | | | | | | | | skeleton CU In cases where .dwo/.dwp files are guaranteed to be available, skipping the extra online (in the .o file) inline info can save a substantial amount of space - see the original r221306 for more details there. llvm-svn: 279650
* Support the DW_AT_noreturn DWARF flag.Adrian Prantl2016-08-171-2/+2
| | | | | | | | | | | This is used to mark functions with the C++11 [[ noreturn ]] or C11 _Noreturn attributes. Patch by Victor Leschuk! https://reviews.llvm.org/D23167 llvm-svn: 278940
* Revert "Revert "Invariant start/end intrinsics overloaded for address space""Mehdi Amini2016-08-131-0/+15
| | | | | | This reverts commit 32fc6488e48eafc0ca1bac1bd9cbf0008224d530. llvm-svn: 278609
* Revert "Invariant start/end intrinsics overloaded for address space"Mehdi Amini2016-08-131-15/+0
| | | | | | This reverts commit r276447. llvm-svn: 278608
* Invariant start/end intrinsics overloaded for address spaceAnna Thomas2016-07-221-0/+15
| | | | | | | | | | | | | | | | | | | | | | Summary: The llvm.invariant.start and llvm.invariant.end intrinsics currently support specifying invariant memory objects only in the default address space. With this change, these intrinsics are overloaded for any adddress space for memory objects and we can use these llvm invariant intrinsics in non-default address spaces. Example: llvm.invariant.start.p1i8(i64 4, i8 addrspace(1)* %ptr) This overloaded intrinsic is needed for representing final or invariant memory in managed languages. Reviewers: apilipenko, reames Subscribers: llvm-commits llvm-svn: 276447
* Revert "Invariant start/end intrinsics overloaded for address space"Anna Thomas2016-07-211-15/+0
| | | | | | This reverts commit r276316. llvm-svn: 276320
* Invariant start/end intrinsics overloaded for address spaceAnna Thomas2016-07-211-0/+15
| | | | | | | | | | | | | | | | | | | | | Summary: The llvm.invariant.start and llvm.invariant.end intrinsics currently support specifying invariant memory objects only in the default address space. With this change, these intrinsics are overloaded for any adddress space for memory objects and we can use these llvm invariant intrinsics in non-default address spaces. Example: llvm.invariant.start.p1i8(i64 4, i8 addrspace(1)* %ptr) This overloaded intrinsic is needed for representing final or invariant memory in managed languages. Reviewers: tstellarAMD, reames, apilipenko Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D22519 llvm-svn: 276316
* [ConstantFold] Don't incorrectly infer inbounds on array GEPDavid Majnemer2016-07-131-0/+10
| | | | | | | | The many levels of nesting inside the responsible code made it easy for bugs to sneak in. Flattening the logic makes it easier to see what's going on. llvm-svn: 275244
* [codeview] Add DISubprogram::ThisAdjustmentReid Kleckner2016-07-011-2/+2
| | | | | | | | | | | | | | | | | | | | | Summary: This represents the adjustment applied to the implicit 'this' parameter in the prologue of a virtual method in the MS C++ ABI. The adjustment is always zero unless multiple inheritance is involved. This increases the size of DISubprogram by 8 bytes, unfortunately. The adjustment really is a signed 32-bit integer. If this size increase is too much, we could probably win it back by splitting out a subclass with info specific to virtual methods (virtuality, vindex, thisadjustment, containingType). Reviewers: aprantl, dexonsmith Subscribers: aaboud, amccarth, llvm-commits Differential Revision: http://reviews.llvm.org/D21614 llvm-svn: 274325
* Support arbitrary addrspace pointers in masked load/store intrinsicsArtur Pilipenko2016-06-281-0/+18
| | | | | | | | | | | | | | This is a resubmittion of 263158 change after fixing the existing problem with intrinsics mangling (see LTO and intrinsics mangling llvm-dev thread for details). This patch fixes the problem which occurs when loop-vectorize tries to use @llvm.masked.load/store intrinsic for a non-default addrspace pointer. It fails with "Calling a function with a bad signature!" assertion in CallInst constructor because it tries to pass a non-default addrspace pointer to the pointer argument which has default addrspace. The fix is to add pointer type as another overloaded type to @llvm.masked.load/store intrinsics. Reviewed By: reames Differential Revision: http://reviews.llvm.org/D17270 llvm-svn: 274043
* Revert -r273892 "Support arbitrary addrspace pointers in masked load/store ↵Artur Pilipenko2016-06-271-18/+0
| | | | | | intrinsics" since some of the clang tests don't expect to see the updated signatures. llvm-svn: 273895
* Support arbitrary addrspace pointers in masked load/store intrinsicsArtur Pilipenko2016-06-271-0/+18
| | | | | | | | | | | | | | This is a resubmittion of 263158 change after fixing the existing problem with intrinsics mangling (see LTO and intrinsics mangling llvm-dev thread for details). This patch fixes the problem which occurs when loop-vectorize tries to use @llvm.masked.load/store intrinsic for a non-default addrspace pointer. It fails with "Calling a function with a bad signature!" assertion in CallInst constructor because it tries to pass a non-default addrspace pointer to the pointer argument which has default addrspace. The fix is to add pointer type as another overloaded type to @llvm.masked.load/store intrinsics. Reviewed By: reames Differential Revision: http://reviews.llvm.org/D17270 llvm-svn: 273892
* IR: Allow metadata attachments on declarations, and fix lazy loaded metadata ↵Peter Collingbourne2016-06-212-4/+16
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | issue with globals. This change is motivated by an upcoming change to the metadata representation used for CFI. The indirect function call checker needs type information for external function declarations in order to correctly generate jump table entries for such declarations. We currently associate such type information with declarations using a global metadata node, but I plan [1] to move all such metadata to global object attachments. In bitcode, metadata attachments for function declarations appear in the global metadata block. This seems reasonable to me because I expect metadata attachments on declarations to be uncommon. In the long term I'd also expect this to be the case for CFI, because we'd want to use some specialized bitcode format for this metadata that could be read as part of the ThinLTO thin-link phase, which would mean that it would not appear in the global metadata block. To solve the lazy loaded metadata issue I was seeing with D20147, I use the same bitcode representation for metadata attachments for global variables as I do for function declarations. Since there's a use case for metadata attachments in the global metadata block, we might as well use that representation for global variables as well, at least until we have a mechanism for lazy loading global variables. In the assembly format, the metadata attachments appear after the "declare" keyword in order to avoid a parsing ambiguity. [1] http://lists.llvm.org/pipermail/llvm-dev/2016-June/100462.html Differential Revision: http://reviews.llvm.org/D21052 llvm-svn: 273336
* IR: Introduce local_unnamed_addr attribute.Peter Collingbourne2016-06-141-0/+13
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | If a local_unnamed_addr attribute is attached to a global, the address is known to be insignificant within the module. It is distinct from the existing unnamed_addr attribute in that it only describes a local property of the module rather than a global property of the symbol. This attribute is intended to be used by the code generator and LTO to allow the linker to decide whether the global needs to be in the symbol table. It is possible to exclude a global from the symbol table if three things are true: - This attribute is present on every instance of the global (which means that the normal rule that the global must have a unique address can be broken without being observable by the program by performing comparisons against the global's address) - The global has linkonce_odr linkage (which means that each linkage unit must have its own copy of the global if it requires one, and the copy in each linkage unit must be the same) - It is a constant or a function (which means that the program cannot observe that the unique-address rule has been broken by writing to the global) Although this attribute could in principle be computed from the module contents, LTO clients (i.e. linkers) will normally need to be able to compute this property as part of symbol resolution, and it would be inefficient to materialize every module just to compute it. See: http://lists.llvm.org/pipermail/llvm-commits/Week-of-Mon-20160509/356401.html http://lists.llvm.org/pipermail/llvm-commits/Week-of-Mon-20160516/356738.html for earlier discussion. Part of the fix for PR27553. Differential Revision: http://reviews.llvm.org/D20348 llvm-svn: 272709
* [DebugInfo] Add calling convention support for DWARF and CodeViewReid Kleckner2016-06-081-2/+11
| | | | | | | | | | | | | | | | | | | | | Summary: Now DISubroutineType has a 'cc' field which should be a DW_CC_ enum. If it is present and non-zero, the backend will emit it as a DW_AT_calling_convention attribute. On the CodeView side, we translate it to the appropriate enum for the LF_PROCEDURE record. I added a new LLVM vendor specific enum to the list of DWARF calling conventions. DWARF does not appear to attempt to standardize these, so I assume it's OK to do this until we coordinate with GCC on how to emit vectorcall convention functions. Reviewers: dexonsmith, majnemer, aaboud, amccarth Subscribers: mehdi_amini, llvm-commits Differential Revision: http://reviews.llvm.org/D21114 llvm-svn: 272197
* IR: Allow multiple global metadata attachments with the same type.Peter Collingbourne2016-06-011-2/+2
| | | | | | | | | | This will be necessary to allow the global merge pass to attach multiple debug info metadata nodes to global variables once we reverse the edge from DIGlobalVariable to GlobalVariable. Differential Revision: http://reviews.llvm.org/D20414 llvm-svn: 271358
* Add support for metadata attachments for global variables.Peter Collingbourne2016-05-311-5/+14
| | | | | | | | | | This patch adds an IR, assembly and bitcode representation for metadata attachments for globals. Future patches will port existing features to use these new attachments. Differential Revision: http://reviews.llvm.org/D20074 llvm-svn: 271348
* Fix constant folding of addrspacecast of nullMatt Arsenault2016-05-211-3/+11
| | | | | | | This should not be making assumptions on the value of the casted pointer. llvm-svn: 270293
* Make "@name =" mandatory for globals in .ll files.Rafael Espindola2016-05-1013-32/+32
| | | | | | | | | | | | | | | | | | | | | | | An oddity of the .ll syntax is that the "@var = " in @var = global i32 42 is optional. Writing just global i32 42 is equivalent to @0 = global i32 42 This means that there is a pretty big First set at the top level. The current implementation maintains it manually. I was trying to refactor it, but then started wondering why keep it a all. I personally find the above syntax confusing. It looks like something is missing. This patch removes the feature and simplifies the parser. llvm-svn: 269096
* DebugInfo: Remove MDString-based type referencesDuncan P. N. Exon Smith2016-04-231-10/+10
| | | | | | | | | | | | | | | | | | | | | | | | Eliminate DITypeIdentifierMap and make DITypeRef a thin wrapper around DIType*. It is no longer legal to refer to a DICompositeType by its 'identifier:', and DIBuilder no longer retains all types with an 'identifier:' automatically. Aside from the bitcode upgrade, this is mainly removing logic to resolve an MDString-based reference to an actualy DIType. The commits leading up to this have made the implicit type map in DICompileUnit's 'retainedTypes:' field superfluous. This does not remove DITypeRef, DIScopeRef, DINodeRef, and DITypeRefArray, or stop using them in DI-related metadata. Although as of this commit they aren't serving a useful purpose, there are patchces under review to reuse them for CodeView support. The tests in LLVM were updated with deref-typerefs.sh, which is attached to the thread "[RFC] Lazy-loading of debug info metadata": http://lists.llvm.org/pipermail/llvm-dev/2016-April/098318.html llvm-svn: 267296
* [AArch64] [ARM] Make a target-independent llvm.thread.pointer intrinsic.Marcin Koscielnicki2016-04-191-0/+19
| | | | | | | | | | | | | | Both AArch64 and ARM support llvm.<arch>.thread.pointer intrinsics that just return the thread pointer. I have a pending patch that does the same for SystemZ (D19054), and there are many more targets that could benefit from one. This patch merges the ARM and AArch64 intrinsics into a single target independent one that will also be used by subsequent targets. Differential Revision: http://reviews.llvm.org/D19098 llvm-svn: 266818
* IR: Fix type-refs in testcase from r266548Duncan P. N. Exon Smith2016-04-171-11/+11
| | | | | | | | | | | | | | | | | There's a hole in the verifier right now: if a module has no compile units, it never checks that all the string-based DITypeRefs get resolved. As a result, this testcase didn't fail the verifier, even there were references to `!"has-uuid"` instead of `!"uuid"` (the former was a composite type's 'name:' field, the latter its 'identifier:' field). I'm currently working on removing string-based type refs entirely, and this testcase started failing (because the upgrade script can't resolve the type refs). Rather than fixing the (about-to-be-removed) hole in the verifier, I'm just going to fix the test so that my upgrade script handles it. llvm-svn: 266553
* IR: Use ODR to unique DICompositeType membersDuncan P. N. Exon Smith2016-04-171-0/+54
| | | | | | | | | | | | | | Merge members that are describing the same member of the same ODR type, even if other bits differ. If the file or line differ, we don't care; if anything else differs, it's an ODR violation (and we still don't really care). For DISubprogram declarations, this looks at the LinkageName and Scope. For DW_TAG_member instances of DIDerivedType, this looks at the Name and Scope. In both cases, we know that the Scope follows ODR rules if it has a non-empty identifier. llvm-svn: 266548
* [PR27284] Reverse the ownership between DICompileUnit and DISubprogram.Adrian Prantl2016-04-1510-127/+128
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Currently each Function points to a DISubprogram and DISubprogram has a scope field. For member functions the scope is a DICompositeType. DIScopes point to the DICompileUnit to facilitate type uniquing. Distinct DISubprograms (with isDefinition: true) are not part of the type hierarchy and cannot be uniqued. This change removes the subprograms list from DICompileUnit and instead adds a pointer to the owning compile unit to distinct DISubprograms. This would make it easy for ThinLTO to strip unneeded DISubprograms and their transitively referenced debug info. Motivation ---------- Materializing DISubprograms is currently the most expensive operation when doing a ThinLTO build of clang. We want the DISubprogram to be stored in a separate Bitcode block (or the same block as the function body) so we can avoid having to expensively deserialize all DISubprograms together with the global metadata. If a function has been inlined into another subprogram we need to store a reference the block containing the inlined subprogram. Attached to https://llvm.org/bugs/show_bug.cgi?id=27284 is a python script that updates LLVM IR testcases to the new format. http://reviews.llvm.org/D19034 <rdar://problem/25256815> llvm-svn: 266446
* Revert "Support arbitrary addrspace pointers in masked load/store intrinsics"Adam Nemet2016-04-141-19/+0
| | | | | | | | This reverts commit r266086. It breaks the LTO build of gcc in SPEC2000. llvm-svn: 266282
* Support arbitrary addrspace pointers in masked load/store intrinsicsArtur Pilipenko2016-04-121-0/+19
| | | | | | | | | | | | | | This is a resubmittion of 263158 change. This patch fixes the problem which occurs when loop-vectorize tries to use @llvm.masked.load/store intrinsic for a non-default addrspace pointer. It fails with "Calling a function with a bad signature!" assertion in CallInst constructor because it tries to pass a non-default addrspace pointer to the pointer argument which has default addrspace. The fix is to add pointer type as another overloaded type to @llvm.masked.load/store intrinsics. Reviewed By: reames Differential Revision: http://reviews.llvm.org/D17270 llvm-svn: 266086
* [SSP] Remove llvm.stackprotectorcheck.Tim Shen2016-04-081-1/+14
| | | | | | | | | | This is a cleanup patch for SSP support in LLVM. There is no functional change. llvm.stackprotectorcheck is not needed, because SelectionDAG isn't actually lowering it in SelectBasicBlock; rather, it adds check code in FinishBasicBlock, ignoring the position where the intrinsic is inserted (See FindSplitPointForStackProtector()). llvm-svn: 265851
* [IFUNC] Fix ifunc-asm.ll testDmitry Polukhin2016-04-081-3/+3
| | | | | | | It seems that llc cannot be called used in assembler tests so test that checks asm for particular target needs to be moved to codegen. llvm-svn: 265770
* Fix test/Assembler/ifunc-asm.ll test on hexagon-elf botsDmitry Polukhin2016-04-071-2/+0
| | | | | | | Temporary disable llc test, it seems that such test should be in some other directory. llvm-svn: 265669
* [GCC] Attribute ifunc support in llvmDmitry Polukhin2016-04-072-0/+56
| | | | | | | | | | | This patch add support for GCC attribute((ifunc("resolver"))) for targets that use ELF as object file format. In general ifunc is a special kind of function alias with type @gnu_indirect_function. Patch for Clang http://reviews.llvm.org/D15524 Differential Revision: http://reviews.llvm.org/D15525 llvm-svn: 265667
* AsmParser: Don't crash on unresolved !tbaaDuncan P. N. Exon Smith2016-04-062-1/+12
| | | | | | | | Instead of crashing, give a nice error. As a drive-by, fix the location associated with the errors for unresolved metadata (the location was off by one token). llvm-svn: 265507
* [DebugInfo] Fix tests so that each subprogram belongs to a CU.Davide Italiano2016-04-052-6/+17
| | | | llvm-svn: 265490
* [DebugInfo] Fix tests in Assembler/Davide Italiano2016-04-046-0/+59
| | | | | | | Each DISubprogram with isDefinition : true must belong to a compile unit. llvm-svn: 265281
* testcase gardening: update the emissionKind enum to the new syntax. (NFC)Adrian Prantl2016-04-012-2/+2
| | | | llvm-svn: 265081
* Move the DebugEmissionKind enum from DIBuilder into DICompileUnit.Adrian Prantl2016-03-314-10/+26
| | | | | | | | | | | | | This mostly cosmetic patch moves the DebugEmissionKind enum from DIBuilder into DICompileUnit. DIBuilder is not the right place for this enum to live in — a metadata consumer should not have to include DIBuilder.h. I also added a Verifier check that checks that the emission kind of a DICompileUnit is actually legal. http://reviews.llvm.org/D18612 <rdar://problem/25427165> llvm-svn: 265077
* Use existing PrintEscapedString in AssemblyWriterTeresa Johnson2016-03-301-2/+2
| | | | | | | r264884 introduced a helper to escape the backslashes in the source file path, but I since discovered an existing mechanism to escape strings. llvm-svn: 264936
* Restore "[ThinLTO] Serialize the Module SourceFileName to/from LLVM assembly"Teresa Johnson2016-03-302-0/+16
| | | | | | | This restores commit 264869, with a fix for windows bots to properly escape '\' in the path when serializing out. Added test. llvm-svn: 264884
* Revert "[ThinLTO] Serialize the Module SourceFileName to/from LLVM assembly"Teresa Johnson2016-03-301-8/+0
| | | | | | | | | This reverts commit r264869. I am seeing Windows bot failures due to the "\" in the path being mishandled at some point (seems to be interpreted wrongly at some point and llvm-as | llvm-dis is yielding some junk characters). Need to investigate. llvm-svn: 264871
* [ThinLTO] Serialize the Module SourceFileName to/from LLVM assemblyTeresa Johnson2016-03-301-0/+8
| | | | | | | | | | | | | | | | | | | Summary: This change serializes out and in the SourceFileName to LLVM assembly so that it is preserved through "llvm-dis | llvm-as". This is necessary to ensure that the global identifiers created for local values in the module summary index are the same even if the bitcode is streamed out and read back from LLVM assembly. Serializing the summary itself to LLVM assembly is in progress. Reviewers: joker.eph Subscribers: llvm-commits, joker.eph Differential Revision: http://reviews.llvm.org/D18588 llvm-svn: 264869
* ADCE: Remove debug info intrinsics in dead scopesDuncan P. N. Exon Smith2016-03-291-1/+1
| | | | | | | | | | | | | | | | | During ADCE, track which debug info scopes still have live references from the code, and delete debug info intrinsics for the dead ones. These intrinsics describe the locations of variables (in registers or stack slots). If there's no code left corresponding to a variable's scope, then there's no way to reference the variable in the debugger and it doesn't matter what its value is. I add a DEBUG printout when the described location in an SSA register, in case it helps some trying to track down why locations get lost. However, we still delete these; the scope itself isn't attached to any real code, so the ship has already sailed. llvm-svn: 264800
* Add an IR Verifier check for orphaned DICompileUnits.Adrian Prantl2016-03-281-0/+5
| | | | | | | | | A DICompileUnit that is not listed in llvm.dbg.cu will cause assertion failures and/or crashes in the backend. The Verifier should reject this. rdar://problem/25369499 llvm-svn: 264657
* IR: Stop upgrading !llvm.loop attachments via MDStringDuncan P. N. Exon Smith2016-03-252-42/+10
| | | | | | | | | | | | Remove logic to upgrade !llvm.loop by changing the MDString tag directly. This old logic would check (and change) arbitrary strings that had nothing to do with loop metadata. Instead, check !llvm.loop attachments directly, and change which strings get attached. Rather than updating the assembly-based upgrade, drop it entirely. It has been quite a while since we supported upgrading textual IR. llvm-svn: 264373
* Revert "Support arbitrary addrspace pointers in masked load/store intrinsics"Matthias Braun2016-03-221-22/+1
| | | | | | | | | | | This commit broke LTO builds. Reverting it to unbreak the bots while the issue is investigated. See also: http://lists.llvm.org/pipermail/llvm-commits/Week-of-Mon-20160321/341002.html This reverts r263158 llvm-svn: 264088
* DebugInfo: Add ability to not emit DW_AT_vtable_elem_location for virtual ↵Peter Collingbourne2016-03-171-4/+22
| | | | | | | | | | | | functions. A virtual index of -1u indicates that the subprogram's virtual index is unrepresentable (for example, when using the relative vtable ABI), so do not emit a DW_AT_vtable_elem_location attribute for it. Differential Revision: http://reviews.llvm.org/D18236 llvm-svn: 263765
* Upgrade TBAA *before* upgrading intrinsicsChris Bieneman2016-03-161-3/+7
| | | | | | | | | | | | Summary: If TBAA is on an intrinsic and it gets upgraded and drops the TBAA we hit an odd assert. We should just upgrade the TBAA first because it doesn't have side-effects. Reviewers: reames, apilipenko, manmanren Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D18229 llvm-svn: 263673
* Support arbitrary addrspace pointers in masked load/store intrinsicsArtur Pilipenko2016-03-101-1/+18
| | | | | | | | | | | | This patch fixes the problem which occurs when loop-vectorize tries to use @llvm.masked.load/store intrinsic for a non-default addrspace pointer. It fails with "Calling a function with a bad signature!" assertion in CallInst constructor because it tries to pass a non-default addrspace pointer to the pointer argument which has default addrspace. The fix is to add pointer type as another overloaded type to @llvm.masked.load/store intrinsics. Reviewed By: reames Differential Revision: http://reviews.llvm.org/D17270 llvm-svn: 263158
* Fix constant folding of constant vector GEPs with undef or null as pointer ↵Manuel Jacob2016-01-191-0/+4
| | | | | | | | | | | | argument. Reviewers: eddyb Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D16321 llvm-svn: 258134
* [ConstantFold] Fix bitcast to gep constant folding transform.David Majnemer2015-12-141-0/+4
| | | | | | | | | | | | Make sure to check that the destination type is sized. A check was present but was incorrectly checking the source type instead. Patch by Amaury SECHET! Differential Revision: http://reviews.llvm.org/D15264 llvm-svn: 255536
* [IR] Reformulate LLVM's EH funclet IRDavid Majnemer2015-12-121-89/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Macro debug info support in LLVM IRAmjad Aboud2015-12-102-12/+22
| | | | | | | | Introduced DIMacro and DIMacroFile debug info metadata in the LLVM IR to support macros. Differential Revision: http://reviews.llvm.org/D14687 llvm-svn: 255245
OpenPOWER on IntegriCloud