summaryrefslogtreecommitdiffstats
path: root/llvm/lib/IR/AsmWriter.cpp
Commit message (Collapse)AuthorAgeFilesLines
* Revert "Don't invoke getName() from Function::isIntrinsic().", rL276942.Justin Lebar2016-07-281-2/+2
| | | | | | | | | This broke some out-of-tree AMDGPU tests that relied on the old behavior wherein isIntrinsic() would return true for any function that starts with "llvm.". And in general that change will not play nicely with out-of-tree backends. llvm-svn: 277087
* Don't invoke getName() from Function::isIntrinsic().Justin Lebar2016-07-271-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: getName() involves a hashtable lookup, so is expensive given how frequently isIntrinsic() is called. (In particular, many users cast to IntrinsicInstr or one of its subclasses before calling getIntrinsicID().) This has an incidental functional change: Before, isIntrinsic() would return true for any function whose name started with "llvm.", even if it wasn't properly an intrinsic. The new behavior seems more correct to me, because it's strange to say that isIntrinsic() is true, but getIntrinsicId() returns "not an intrinsic". Some callers want the old behavior -- they want to know whether the caller is a recognized intrinsic, or might be one in some other version of LLVM. For them, we added Function::hasLLVMReservedName(), which checks whether the name starts with "llvm.". This change is good for a 1.5% e2e speedup compiling a large Eigen benchmark. Reviewers: bogner Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D22065 llvm-svn: 276942
* [codeview] Add DISubprogram::ThisAdjustmentReid Kleckner2016-07-011-0/+1
| | | | | | | | | | | | | | | | | | | | | 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
* Apply clang-tidy's modernize-loop-convert to most of lib/IR.Benjamin Kramer2016-06-261-8/+7
| | | | | | Only minor manual fixes. No functionality change intended. llvm-svn: 273813
* IR: Introduce Module::global_objects().Peter Collingbourne2016-06-221-5/+2
| | | | | | | | | | | | This is a convenience iterator that allows clients to enumerate the GlobalObjects within a Module. Also start using it in a few places where it is obviously the right thing to use. Differential Revision: http://reviews.llvm.org/D21580 llvm-svn: 273470
* IR: Allow metadata attachments on declarations, and fix lazy loaded metadata ↵Peter Collingbourne2016-06-211-8/+13
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Add llvm_unreachable to silence a "not all control paths" false positive ↵Aaron Ballman2016-06-151-0/+1
| | | | | | warning from MSVC. llvm-svn: 272793
* IR: Introduce local_unnamed_addr attribute.Peter Collingbourne2016-06-141-6/+20
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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-0/+1
| | | | | | | | | | | | | | | | | | | | | 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
* Add support for metadata attachments for global variables.Peter Collingbourne2016-05-311-2/+13
| | | | | | | | | | 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
* Try to fix a msvc warning.Rafael Espindola2016-05-111-0/+1
| | | | llvm-svn: 269178
* Replace PrintLinkage with getLinkagePrintName. NFC.Rafael Espindola2016-05-111-17/+25
| | | | llvm-svn: 269155
* AMDGPU/SI: Add amdgpu_kernel calling convention. Part 1.Nikolay Haustov2016-05-061-0/+1
| | | | | | | | | | | | | | | | | Summary: This will be used for AMDGPU_HSA_KERNEL symbol type in output ELF. Also, in the future unused non-kernels may be optimized. For now, also accept SPIR_KERNEL for HCC frontend. Also, add bitcode compatibility tests for missing calling conventions except AVR_BUILTIN which doesn't have parse code. Reviewers: tstellarAMD, arsenm Subscribers: arsenm, joker.eph, llvm-commits llvm-svn: 268717
* IR: Avoid mallocs in constructor of ModuleSlotTrackerDuncan P. N. Exon Smith2016-04-201-4/+15
| | | | | | | | A ModuleSlotTracker can be created without actually being used (e.g., r266889 added one to the Verifier). Create the SlotTracker within it lazily on the first call to ModuleSlotTracker::getMachine. llvm-svn: 266902
* IR: Use a single ModuleSlotTracker in the VerifierDuncan P. N. Exon Smith2016-04-201-0/+16
| | | | | | | | | | | | Speed up Verifier output by sharing a single ModuleSlotTracker for the duration. There should be no functionality change here except for much faster output when there's more than one statement. Now the Verifier won't be traversing the full Metadata graph every time it prints an error. The TypePrinter is still not shared, but that would take some extra plumbing. llvm-svn: 266889
* [PR27284] Reverse the ownership between DICompileUnit and DISubprogram.Adrian Prantl2016-04-151-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* [GCC] Attribute ifunc support in llvmDmitry Polukhin2016-04-071-3/+28
| | | | | | | | | | | 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
* NFC: make AtomicOrdering an enum classJF Bastien2016-04-061-30/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* AMDGPU: Add a shader calling conventionNicolai Haehnle2016-04-061-0/+4
| | | | | | | | | | | This makes it possible to distinguish between mesa shaders and other kernels even in the presence of compute shaders. Patch By: Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl> Differential Revision: http://reviews.llvm.org/D18559 llvm-svn: 265589
* Swift Calling Convention: add swiftcc.Manman Ren2016-04-051-0/+1
| | | | | | Differential Revision: http://reviews.llvm.org/D17863 llvm-svn: 265480
* [IFUNC] Use GlobalIndirectSymbol when aliases and ifuncs have something similarDmitry Polukhin2016-04-051-18/+21
| | | | | | | | | | | Second part extracted from http://reviews.llvm.org/D15525 Use GlobalIndirectSymbol in all cases when aliases and ifuncs have something in common. Differential Revision: http://reviews.llvm.org/D18754 llvm-svn: 265382
* Swift Calling Convention: add swifterror attribute.Manman Ren2016-04-011-0/+2
| | | | | | | | | | | | 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
* Move the DebugEmissionKind enum from DIBuilder into DICompileUnit.Adrian Prantl2016-03-311-2/+8
| | | | | | | | | | | | | 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-19/+3
| | | | | | | 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-301-0/+22
| | | | | | | 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-3/+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/+3
| | | | | | | | | | | | | | | | | | | 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
* DebugInfo: Add ability to not emit DW_AT_vtable_elem_location for virtual ↵Peter Collingbourne2016-03-171-1/+3
| | | | | | | | | | | | 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
* [IR] Provide an API to skip the details of a structured type when printed.Quentin Colombet2016-03-071-1/+4
| | | | | | | The mir infrastructure will need this for generic instructions and currently this feature was only available through the anonymous TypePrinter class. llvm-svn: 262869
* [AVR] Add calling convention parser tokensDylan McKay2016-03-031-0/+2
| | | | | | | | | | | | Summary: Adds the 'avr_intrcc' and 'avr_signalcc' IR calling convention tokens to the parser. Reviewers: arsenm Subscribers: dylanmckay, llvm-commits Differential Revision: http://reviews.llvm.org/D16348 llvm-svn: 262600
* This patch adds MemorySSA to LLVM.George Burgess IV2016-02-021-0/+11
| | | | | | | | | Please see include/llvm/Transforms/Utils/MemorySSA.h for a description of MemorySSA, and what it does. Differential Revision: http://reviews.llvm.org/D7864 llvm-svn: 259595
* Tweak unnamed label syntax in textual IR for easier matching in tests.Evgeniy Stepanov2016-01-271-1/+1
| | | | | | | | | | | Change the unnamed label comments like ; <label>:8 ; preds = %1 to ; <label>:8: ; preds = %1 This way lit tests can match [[LABEL]]: in both asserts and no-asserts builds. llvm-svn: 258993
* GlobalValue: use getValueType() instead of getType()->getPointerElementType().Manuel Jacob2016-01-161-1/+1
| | | | | | | | | | | | Reviewers: mjacob Subscribers: jholewinski, arsenm, dsanders, dblaikie Patch by Eduard Burtescu. Differential Revision: http://reviews.llvm.org/D16260 llvm-svn: 257999
* Fix crash when printing instructions that have a metadata attached but no ↵Mehdi Amini2016-01-071-1/+1
| | | | | | | | | | | | | | | | | | parent. Fix PR24852 (crash with -debug -instcombine) Patch by Than McIntosh <thanm@google.com> Summary: Add guards to the asm writer to prevent crashing when dumping an instruction that has no basic block. Differential Revision: http://reviews.llvm.org/D15798 From: Than McIntosh <thanm@google.com> llvm-svn: 257094
* [Statepoints] Refactor GCRelocateOperands into an intrinsic wrapper. NFC.Manuel Jacob2016-01-051-9/+6
| | | | | | | | | | | | | | | 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
* Implemented Support of IA interrupt and exception handlers:Amjad Aboud2015-12-211-0/+1
| | | | | | | | http://lists.llvm.org/pipermail/cfe-dev/2015-September/045171.html Differential Revision: http://reviews.llvm.org/D15567 llvm-svn: 256155
* Re-reapply "[IR] Move optional data in llvm::Function into a hungoff uselist"Vedant Kumar2015-12-191-13/+5
| | | | | | | | | | | | | | | | | Make personality functions, prefix data, and prologue data hungoff operands of Function. This is based on the email thread "[RFC] Clean up the way we store optional Function data" on llvm-dev. Thanks to sanjoyd, majnemer, rnk, loladiro, and dexonsmith for feedback! Includes a fix to scrub value subclass data in dropAllReferences. Does not use binary literals. Differential Revision: http://reviews.llvm.org/D13829 llvm-svn: 256095
* Revert "Reapply "[IR] Move optional data in llvm::Function into a hungoff ↵Vedant Kumar2015-12-191-5/+13
| | | | | | | | | | uselist"" This reverts commit r256093. This broke lld-x86_64-win7 because of -Werror,-Wc++1y-extensions. llvm-svn: 256094
* Reapply "[IR] Move optional data in llvm::Function into a hungoff uselist"Vedant Kumar2015-12-191-13/+5
| | | | | | | | | | | | | | | | Make personality functions, prefix data, and prologue data hungoff operands of Function. This is based on the email thread "[RFC] Clean up the way we store optional Function data" on llvm-dev. Thanks to sanjoyd, majnemer, rnk, loladiro, and dexonsmith for feedback! Includes a fix to scrub value subclass data in dropAllReferences. Differential Revision: http://reviews.llvm.org/D13829 llvm-svn: 256093
* Revert "[IR] Move optional data in llvm::Function into a hungoff uselist"Vedant Kumar2015-12-191-5/+13
| | | | | | | | This reverts commit r256090. This broke llvm-clang-lld-x86_64-debian-fast. llvm-svn: 256091
* [IR] Move optional data in llvm::Function into a hungoff uselistVedant Kumar2015-12-191-13/+5
| | | | | | | | | | | | | | Make personality functions, prefix data, and prologue data hungoff operands of Function. This is based on the email thread "[RFC] Clean up the way we store optional Function data" on llvm-dev. Thanks to sanjoyd, majnemer, rnk, loladiro, and dexonsmith for feedback! Differential Revision: http://reviews.llvm.org/D13829 llvm-svn: 256090
* [IR] Remove terminatepadDavid Majnemer2015-12-141-15/+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-36/+30
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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-101-0/+33
| | | | | | | | Introduced DIMacro and DIMacroFile debug info metadata in the LLVM IR to support macros. Differential Revision: http://reviews.llvm.org/D14687 llvm-svn: 255245
* [CXX TLS calling convention] Add CXX TLS calling convention.Manman Ren2015-12-041-0/+1
| | | | | | | | | | | | | | | | | | | | | This commit adds a new target-independent calling convention for C++ TLS access functions. It aims to minimize overhead in the caller by perserving as many registers as possible. The target-specific implementation for X86-64 is defined as following: Arguments are passed as for the default C calling convention The same applies for the return value(s) The callee preserves all GPRs - except RAX and RDI The access function makes C-style TLS function calls in the entry and exit block, C-style TLS functions save a lot more registers than normal calls. The added calling convention ties into the existing implementation of the C-style TLS functions, so we can't simply use existing calling conventions such as preserve_mostcc. rdar://9001553 llvm-svn: 254737
* IR: Use format_hex instead of handrolling the conversion. NFCJustin Bogner2015-12-041-47/+17
| | | | | | Cleans up some very old code in AsmWriter's WriteConstantInternal. llvm-svn: 254688
* IR: Update a comment and a bool that've been out of date since 2012Justin Bogner2015-12-041-3/+2
| | | | | | | It became impossible to get here with a half in r157393, over 3 years ago. llvm-svn: 254679
* [IR] Add support for empty tokensDavid Majnemer2015-11-111-0/+5
| | | | | | | | | | | | | | When working with tokens, it is often the case that one has instructions which consume a token and produce a new token. Currently, we have no mechanism to represent an initial token state. Instead, we can create a notional "empty token" by inventing a new constant which captures the semantics we would like. This new constant is called ConstantTokenNone and is written textually as "token none". Differential Revision: http://reviews.llvm.org/D14581 llvm-svn: 252811
* [OperandBundles] Identify operand bundles with both their names and IDsSanjoy Das2015-11-101-1/+1
| | | | | | | No code uses this functionality yet. This change just exposes information / structure that was already present. llvm-svn: 252644
* [OperandBundles] Rename accessor, NFCSanjoy Das2015-11-071-1/+1
| | | | | | Rename getOperandBundle to getOperandBundleAt since that's more obvious. llvm-svn: 252388
OpenPOWER on IntegriCloud