summaryrefslogtreecommitdiffstats
path: root/llvm/lib/IR
Commit message (Collapse)AuthorAgeFilesLines
* Don't upgrade global constructors when reading bitcodeDuncan P. N. Exon Smith2014-08-121-55/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | An optional third field was added to `llvm.global_ctors` (and `llvm.global_dtors`) in r209015. Most of the code has been changed to deal with both versions of the variables. Users of the C API might create either version, the helper functions in LLVM create the two-field version, and clang now creates the three-field version. However, the BitcodeReader was changed to always upgrade to the three-field version. This created an unnecessary inconsistency in the IR before/after serializing to bitcode. This commit resolves the inconsistency by making the third field truly optional (and not upgrading in the bitcode reader). Since `llvm-link` was relying on this upgrade code, rather than deleting it I've moved it into `ModuleLinker`, where it upgrades these arrays as necessary to resolve inconsistencies between modules. The ideal resolution would be to remove the 2-field version and make the third field required. I filed PR20506 to track that. I changed `test/Bitcode/upgrade-global-ctors.ll` to a negative test and duplicated the `llvm-link` check in `test/Linker/global_ctors.ll` to check both upgrade directions. Since I came across this as part of PR5680 (serializing use-list order), I've also added the missing `verify-uselistorder` RUN line to `test/Bitcode/metadata-2.ll`. llvm-svn: 215457
* IR: Print a newline when dumping TypesJustin Bogner2014-08-121-1/+1
| | | | | | | | | | | | Type::dump() doesn't print a newline, which makes for a poor experience in a debugger. This looks like it was an ommission considering Value::dump() two lines above, so I've changed Type to add a newline as well. Of the two in-tree callers, one added a newline anyway, and I've updated the other one to use Type::print instead. llvm-svn: 215421
* [LLVM-C] Expose User::getOperandUse as LLVMGetOperandUse.Peter Zotov2014-08-121-0/+5
| | | | | | Patch by Gabriel Radanne <drupyog@zoho.com> llvm-svn: 215419
* Move helper for getting a terminating musttail call to BasicBlockReid Kleckner2014-08-121-0/+31
| | | | | | | | | | | No functional change. To be used in future commits that need to look for such instructions. Reviewed By: rafael Differential Revision: http://reviews.llvm.org/D4504 llvm-svn: 215413
* Fix typos:Sylvestre Ledru2014-08-111-1/+1
| | | | | | | * libaries => libraries * avaiable => available llvm-svn: 215366
* pr20588: add missing calls to va_end.Rafael Espindola2014-08-081-2/+7
| | | | llvm-svn: 215212
* Revert "Reapply "DebugInfo: Ensure that all debug location scope chains from ↵David Blaikie2014-08-061-26/+0
| | | | | | | | | | | instructions within a function, lead to the function itself."" This reverts commit r214761. Revert while Reid investigates & provides a reproduction for an assertion failure for this on Windows. llvm-svn: 214999
* Don't count inreg params when mangling fastcall functionsReid Kleckner2014-08-061-0/+3
| | | | | | This is consistent with MSVC. llvm-svn: 214981
* Provide convenient access to the zext/sext attributes of function arguments. ↵Juergen Ributzka2014-08-051-0/+14
| | | | | | NFC. llvm-svn: 214843
* Reapply "DebugInfo: Ensure that all debug location scope chains from ↵David Blaikie2014-08-041-0/+26
| | | | | | | | | | | | | | instructions within a function, lead to the function itself." Originally reverted in r213432 with flakey failures on an ASan self-host build. After reduction it seems to be the same issue fixed in r213805 (ArgPromo + DebugInfo: Handle updating debug info over multiple applications of argument promotion) and r213952 (by having LiveDebugVariables strip dbg_value intrinsics in functions that are not described by debug info). Though I cannot explain why this failure was flakey... llvm-svn: 214761
* [LLVM-C] Add LLVM{IsConstantString,GetAsString,GetElementAsConstant}.Peter Zotov2014-08-031-0/+16
| | | | llvm-svn: 214676
* IR: Add Value::reverseUseList()Duncan P. N. Exon Smith2014-08-011-0/+19
| | | | | | I'm going to use this to improve `verify-uselistorder`. Part of PR5680. llvm-svn: 214594
* verify-uselistorder: Move shuffleUseLists() out of lib/IRDuncan P. N. Exon Smith2014-08-011-104/+2
| | | | | | | | | | `shuffleUseLists()` is only used in `verify-uselistorder`, so move it there to avoid bloating other executables. As a drive-by, update some of the header docs. This is part of PR5680. llvm-svn: 214592
* UseListOrder: Guarantee that shuffles change use-list orderDuncan P. N. Exon Smith2014-08-011-9/+12
| | | | | | | | | Change shuffleUseLists() always to change use-list order by rejecting orders that have no changes. This is part of PR5680. llvm-svn: 214584
* Debug info: Infrastructure to support debug locations for fragmentedAdrian Prantl2014-08-012-0/+70
| | | | | | | | | | | | | | | | | | | | | | | | variables (for example, by-value struct arguments passed in registers, or large integer values split across several smaller registers). On the IR level, this adds a new type of complex address operation OpPiece to DIVariable that describes size and offset of a variable fragment. On the DWARF emitter level, all pieces describing the same variable are collected, sorted and emitted as DWARF expressions using the DW_OP_piece and DW_OP_bit_piece operators. http://reviews.llvm.org/D3373 rdar://problem/15928306 What this patch doesn't do / Future work: - This patch only adds the backend machinery to make this work, patches that change SROA and SelectionDAG's type legalizer to actually create such debug info will follow. (http://reviews.llvm.org/D2680) - Making the DIVariable complex expressions into an argument of dbg.value will reduce the memory footprint of the debug metadata. - The sorting/uniquing of pieces should be moved into DebugLocEntry, to facilitate the merging of multi-piece entries. llvm-svn: 214576
* IR: Add BasicBlock::insertInto()Duncan P. N. Exon Smith2014-08-011-6/+13
| | | | | | | | | | | | | | | | | | | Although unlinked `BasicBlock`s can be created, there's currently no way to insert them into `Function`s after the fact. In particular, `moveAfter()` and `moveBefore()` require that the basic block is already linked. Extract the logic for initially linking a `BasicBlock` out of the constructor and into a member function that can be used for lazy insertion. - Asserts that the basic block is currently unlinked. - Matches the logic of the constructor. - Changed the constructor to use it since the logic matches. This is needed in a follow-up commit for PR5680. llvm-svn: 214563
* [pr20127] Check for leading \1 in the Twine version of getNameWithPrefix.Rafael Espindola2014-08-011-8/+8
| | | | | | | No functionality change, but will simplify an upcoming patch that uses the Twine version. llvm-svn: 214515
* Use "weak alias" instead of "alias weak"Rafael Espindola2014-07-301-2/+1
| | | | | | | | | | | | | | | | | | | | | Before this patch we had @a = weak global ... but @b = alias weak ... The patch changes aliases to look more like global variables. Looking at some really old code suggests that the reason was that the old bison based parser had a reduction for alias linkages and another one for global variable linkages. Putting the alias first avoided the reduce/reduce conflict. The days of the old .ll parser are long gone. The new one parses just "linkage" and a later check is responsible for deciding if a linkage is valid in a given context. llvm-svn: 214355
* Feedback on r214189, no functionality change.Manman Ren2014-07-291-1/+1
| | | | llvm-svn: 214240
* [Debug Info] remove DITrivialType and use null to represent unspecified param.Manman Ren2014-07-292-26/+5
| | | | | | | | | | | | Per feedback on r214111, we are going to use null to represent unspecified parameter. If the type array is {null}, it means a function that returns void; If the type array is {null, null}, it means a variadic function that returns void. In summary if we have more than one element in the type array and the last element is null, it is a variadic function. rdar://17628609 llvm-svn: 214189
* IR: Augment debug statements for use-list orderDuncan P. N. Exon Smith2014-07-291-2/+5
| | | | llvm-svn: 214155
* [Debug Info] add DISubroutineType and its creation takes DITypeArray. Manman Ren2014-07-282-4/+14
| | | | | | | | | | | DITypeArray is an array of DITypeRef, at its creation, we will create DITypeRef (i.e use the identifier if the type node has an identifier). This is the last patch to unique the type array of a subroutine type. rdar://17628609 llvm-svn: 214132
* [Debug Info] add a template class DITypedArray.Manman Ren2014-07-282-10/+13
| | | | | | | | | | | | Typedef DIArray to DITypedArray<DIDescriptor>. Also typedef DITypeArray as DITypedArray<DITypeRef>. This is the third of a series of patches to handle type uniqueing of the type array for a subroutine type. This commit should have no functionality change. llvm-svn: 214115
* [Debug Info] rename getTypeArray to getElements, setTypeArray to setArrays.Manman Ren2014-07-281-3/+3
| | | | | | | | | | | | | | | This is the second of a series of patches to handle type uniqueing of the type array for a subroutine type. For vector and array types, getElements returns the array of subranges, so it is a better name than getTypeArray. Even for class, struct and enum types, getElements returns the members, which can be subprograms. setArrays can set up to two arrays, the second is the templates. This commit should have no functionality change. llvm-svn: 214112
* [Debug Info] replace DIUnspecifiedParameter with DITrivialType.Manman Ren2014-07-282-11/+17
| | | | | | | | | | | | | This is the first of a series of patches to handle type uniqueing of the type array for a subroutine type. This commit makes sure unspecified_parameter is a DIType to enable converting the type array for a subroutine type to an array of DITypes. This commit should have no functionality change. With this commit, we may change unspecified type to be a DITrivialType instead of a DIType. llvm-svn: 214111
* Fix MSVC2012 build error in UseListOrder.cppHans Wennborg2014-07-251-3/+4
| | | | | | | | | I think the compiler got confused by the nested DEBUG macros. It was failing with: UseListOrder.cpp(80) : error C2059: syntax error : '}' llvm-svn: 213954
* Simplify and improve scoped-noalias metadata semanticsHal Finkel2014-07-251-5/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | In the process of fixing the noalias parameter -> metadata conversion process that will take place during inlining (which will be committed soon, but not turned on by default), I have come to realize that the semantics provided by yesterday's commit are not really what we want. Here's why: void foo(noalias a, noalias b, noalias c, bool x) { *q = x ? a : b; *c = *q; } Generically, we know that *c does not alias with *a and with *b (so there is an 'and' in what we know we're not), and we know that *q might be derived from *a or from *b (so there is an 'or' in what we know that we are). So we do not want the semantics currently, where any noalias scope matching any alias.scope causes a NoAlias return. What we want to know is that the noalias scopes form a superset of the alias.scope list (meaning that all the things we know we're not is a superset of all of things the other instruction might be). Making that change, however, introduces a composibility problem. If we inline once, adding the noalias metadata, and then inline again adding more, and we append new scopes onto the noalias and alias.scope lists each time. But, this means that we could change what was a NoAlias result previously into a MayAlias result because we appended an additional scope onto one of the alias.scope lists. So, instead of giving scopes the ability to have parents (which I had borrowed from the TBAA implementation, but seems increasingly unlikely to be useful in practice), I've given them domains. The subset/superset condition now applies within each domain independently, and we only need it to hold in one domain. Each time we inline, we add the new scopes in a new scope domain, and everything now composes nicely. In addition, this simplifies the implementation. llvm-svn: 213948
* Try to fix a layering violation introduced by r213945Duncan P. N. Exon Smith2014-07-251-303/+9
| | | | | | | | | | | The dragonegg buildbot (and others?) started failing after r213945/r213946 because `llvm-as` wasn't linking in the bitcode reader. I think moving the verify functions to the same file as the verify pass should fix the build. Adding a command-line option for maintaining use-list order in assembly as a drive-by to prevent warnings about unused static functions. llvm-svn: 213947
* Fix -Werror build after r213945Duncan P. N. Exon Smith2014-07-251-0/+1
| | | | llvm-svn: 213946
* IPO: Add use-list-order verifierDuncan P. N. Exon Smith2014-07-252-0/+424
| | | | | | | | | | | | | | | | | | | | Add a -verify-use-list-order pass, which shuffles use-list order, writes to bitcode, reads back, and verifies that the (shuffled) order matches. - The utility functions live in lib/IR/UseListOrder.cpp. - Moved (and renamed) the command-line option to enable writing use-lists, so that this pass can return early if the use-list orders aren't being serialized. It's not clear that this pass is the right direction long-term (perhaps a separate tool instead?), but short-term it's a great way to test the use-list order prototype. I've added an XFAIL-ed testcase that I'm hoping to get working pretty quickly. This is part of PR5680. llvm-svn: 213945
* Add scoped-noalias metadataHal Finkel2014-07-244-9/+91
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This commit adds scoped noalias metadata. The primary motivations for this feature are: 1. To preserve noalias function attribute information when inlining 2. To provide the ability to model block-scope C99 restrict pointers Neither of these two abilities are added here, only the necessary infrastructure. In fact, there should be no change to existing functionality, only the addition of new features. The logic that converts noalias function parameters into this metadata during inlining will come in a follow-up commit. What is added here is the ability to generally specify noalias memory-access sets. Regarding the metadata, alias-analysis scopes are defined similar to TBAA nodes: !scope0 = metadata !{ metadata !"scope of foo()" } !scope1 = metadata !{ metadata !"scope 1", metadata !scope0 } !scope2 = metadata !{ metadata !"scope 2", metadata !scope0 } !scope3 = metadata !{ metadata !"scope 2.1", metadata !scope2 } !scope4 = metadata !{ metadata !"scope 2.2", metadata !scope2 } Loads and stores can be tagged with an alias-analysis scope, and also, with a noalias tag for a specific scope: ... = load %ptr1, !alias.scope !{ !scope1 } ... = load %ptr2, !alias.scope !{ !scope1, !scope2 }, !noalias !{ !scope1 } When evaluating an aliasing query, if one of the instructions is associated with an alias.scope id that is identical to the noalias scope associated with the other instruction, or is a descendant (in the scope hierarchy) of the noalias scope associated with the other instruction, then the two memory accesses are assumed not to alias. Note that is the first element of the scope metadata is a string, then it can be combined accross functions and translation units. The string can be replaced by a self-reference to create globally unqiue scope identifiers. [Note: This overview is slightly stylized, since the metadata nodes really need to just be numbers (!0 instead of !scope0), and the scope lists are also global unnamed metadata.] Existing noalias metadata in a callee is "cloned" for use by the inlined code. This is necessary because the aliasing scopes are unique to each call site (because of possible control dependencies on the aliasing properties). For example, consider a function: foo(noalias a, noalias b) { *a = *b; } that gets inlined into bar() { ... if (...) foo(a1, b1); ... if (...) foo(a2, b2); } -- now just because we know that a1 does not alias with b1 at the first call site, and a2 does not alias with b2 at the second call site, we cannot let inlining these functons have the metadata imply that a1 does not alias with b2. llvm-svn: 213864
* AA metadata refactoring (introduce AAMDNodes)Hal Finkel2014-07-241-0/+4
| | | | | | | | | | | | | | | | | | | | In order to enable the preservation of noalias function parameter information after inlining, and the representation of block-level __restrict__ pointer information (etc.), additional kinds of aliasing metadata will be introduced. This metadata needs to be carried around in AliasAnalysis::Location objects (and MMOs at the SDAG level), and so we need to generalize the current scheme (which is hard-coded to just one TBAA MDNode*). This commit introduces only the necessary refactoring to allow for the introduction of other aliasing metadata types, but does not actually introduce any (that will come in a follow-up commit). What it does introduce is a new AAMDNodes structure to hold all of the aliasing metadata nodes associated with a particular memory-accessing instruction, and uses that structure instead of the raw MDNode* in AliasAnalysis::Location, etc. No functionality change intended. llvm-svn: 213859
* Rename metadata llvm.loop.vectorize.unroll to llvm.loop.vectorize.interleave.Mark Heffernan2014-07-211-2/+4
| | | | llvm-svn: 213588
* Revert "[C++11] Add predecessors(BasicBlock *) / successors(BasicBlock *) ↵Duncan P. N. Exon Smith2014-07-213-4/+7
| | | | | | | | | iterator ranges." This reverts commit r213474 (and r213475), which causes a miscompile on a stage2 LTO build. I'll reply on the list in a moment. llvm-svn: 213562
* [C++11] Add predecessors(BasicBlock *) / successors(BasicBlock *) iterator ↵Manuel Jacob2014-07-203-7/+4
| | | | | | | | | | | | | | | | | | ranges. Summary: This patch introduces two new iterator ranges and updates existing code to use it. No functional change intended. Test Plan: All tests (make check-all) still pass. Reviewers: dblaikie Reviewed By: dblaikie Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D4481 llvm-svn: 213474
* Handle AddrSpaceCast in stripAndAccumulateInBoundsConstantOffsetsHal Finkel2014-07-191-1/+2
| | | | | | | | All of the other similar functions in that part of the file look through addrspacecast in addition to bitcast, and I see no reason why stripAndAccumulateInBoundsConstantOffsets shouldn't do so also. llvm-svn: 213449
* Make Value::isDereferenceablePointer handle offsets to pointer types with ↵Hal Finkel2014-07-191-0/+21
| | | | | | | | | | | | | | | | | | dereferenceable attributes When we have a parameter (or call site return) with a dereferenceable attribute, it can specify the size of an array pointed to by that parameter. If we have a value for which we can accumulate a constant offset to such a parameter, then we can use that offset in a direct comparison with the size specified by the dereferenceable attribute. This enables us to handle cases like this: int foo(int a[static 3]) { return a[2]; /* this is always dereferenceable */ } llvm-svn: 213447
* Revert "Reapply "DebugInfo: Ensure that all debug location scope chains from ↵Eric Christopher2014-07-181-26/+0
| | | | | | | | | | instructions within a function, lead to the function itself."""" After a successful build it seems to have come back on a later build. This reverts commit r213391. llvm-svn: 213432
* Rename DiagnosticInfoOptimizationWarning to DiagnosticInfoOptimizationFailureTyler Nowicki2014-07-181-3/+3
| | | | | | | | so the severity of the message is not part of the type name. Reviewed by Alp Toker llvm-svn: 213399
* Reapply "DebugInfo: Ensure that all debug location scope chains from ↵David Blaikie2014-07-181-0/+26
| | | | | | | | | | | | | | | | | instructions within a function, lead to the function itself.""" Recommits 212776 which was reverted in r212793. This has been committed and recommitted a few times as I try to test it harder and find/fix more issues. The most recent revert was due to an asan bot failure which I can't seem to reproduce locally, though I believe I'm following all the steps the buildbot does. So I'm going to recommit this in the hopes of investigating the failure on the buildbot itself... apologies in advance for the bot noise. If anyone sees failures with this /please/ provide me with any reproductions, etc. llvm-svn: 213391
* Add a dereferenceable attributeHal Finkel2014-07-184-11/+116
| | | | | | | | | This attribute indicates that the parameter or return pointer is dereferenceable. Practically speaking, loads from such a pointer within the associated byte range are safe to speculatively execute. Such pointer parameters are common in source languages (C++ references, for example). llvm-svn: 213385
* Rename AlignAttribute to IntAttributeHal Finkel2014-07-182-25/+25
| | | | | | | | | | | | Currently the only kind of integer IR attributes that we have are alignment attributes, and so the attribute kind that takes an integer parameter is called AlignAttr, but that will change (we'll soon be adding a dereferenceable attribute that also takes an integer value). Accordingly, rename AlignAttribute to IntAttribute (class names, enums, etc.). No functionality change intended. llvm-svn: 213352
* Remove unnecessary/redundant std::moveDavid Blaikie2014-07-161-1/+1
| | | | | | (run returns unique_ptr by value already) llvm-svn: 213174
* Emit warnings if vectorization is forced and fails.Tyler Nowicki2014-07-161-6/+23
| | | | | | | | | | | This patch modifies the existing DiagnosticInfo system to create a generic base class that is inherited to produce diagnostic-based warnings. This is used by the loop vectorizer to trigger a warning when vectorization is forced and fails. Several tests have been added to verify this behavior. Reviewed by: Arnold Schwaighofer llvm-svn: 213110
* Document the maximum LLVM IR alignment, which is 1 << 29 or 0.5 GiBReid Kleckner2014-07-151-0/+8
| | | | | | | Add verifier checks. We already check these in the assembly parser, but a frontend producing IR in memory wouldn't hit those checks. llvm-svn: 213027
* Look through addrspacecast when checking isDereferenceablePointerMatt Arsenault2014-07-141-0/+3
| | | | llvm-svn: 212971
* Add CreatePointerBitCastOrAddrSpaceCast to IRBuilder and co.Matt Arsenault2014-07-141-8/+26
| | | | llvm-svn: 212962
* IR: Allow comdats to be applied to globals with internal linkageDavid Majnemer2014-07-131-4/+3
| | | | | | | | | | Our verifier check for checking if a global has local linkage was too strict. Forbid private linkage but permit local linkage. Object file formats permit this and forbidding it prevents elimination of unused, internal, vftables under the MSVC ABI. llvm-svn: 212900
* Revert "Reapply "DebugInfo: Ensure that all debug location scope chains from ↵David Blaikie2014-07-111-26/+0
| | | | | | | | | | | | instructions within a function, lead to the function itself."" This reverts commit r212776. Nope, still seems to be failing on the sanitizer bots... but hey, not the msan self-host anymore, it's failing in asan now. I'll start looking there next. llvm-svn: 212793
* Reapply "DebugInfo: Ensure that all debug location scope chains from ↵David Blaikie2014-07-101-0/+26
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | instructions within a function, lead to the function itself." Committed in r212205 and reverted in r212226 due to msan self-hosting failure, I believe I've got that fixed by r212761 to Clang. Original commit message: "Originally committed in r211723, reverted in r211724 due to failure cases found and fixed (ArgumentPromotion: r211872, Inlining: r212065), committed again in r212085 and reverted again in r212089 after fixing some other cases, such as debug info subprogram lists not keeping track of the function they represent (r212128) and then short-circuiting things like LiveDebugVariables that build LexicalScopes for functions that might not have full debug info. And again, I believe the invariant actually holds for some reasonable amount of code (but I'll keep an eye on the buildbots and see what happens... ). Original commit message: PR20038: DebugInfo: Inlined call sites where the caller has debug info but the call itself has no debug location. This situation does bad things when inlined, so I've fixed Clang not to produce inlinable call sites without locations when the caller has debug info (in the one case where I could find that this occurred). This updates the PR20038 test case to be what clang now produces, and readds the assertion that had to be removed due to this bug. I've also beefed up the debug info verifier to help diagnose these issues in the future, and I hope to add checks to the inliner to just assert-fail if it encounters this situation. If, in the future, we decide we have to cope with this situation, the right thing to do is probably to just remove all the DebugLocs from the inlined instructions." llvm-svn: 212776
OpenPOWER on IntegriCloud