summaryrefslogtreecommitdiffstats
path: root/llvm/lib/IR
Commit message (Collapse)AuthorAgeFilesLines
* 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-105-5/+127
| | | | | | | | Introduced DIMacro and DIMacroFile debug info metadata in the LLVM IR to support macros. Differential Revision: http://reviews.llvm.org/D14687 llvm-svn: 255245
* Add arg_begin() and arg_end() to CallInst and InvokeInst; NFCISanjoy Das2015-12-101-4/+2
| | | | | | | | | | - This simplifies the CallSite class, arg_begin / arg_end are now simple wrapper getters. - In several places, we were creating CallSite instances solely to call arg_begin and arg_end. With this change, that's no longer required. llvm-svn: 255226
* IR: Make ConstantDataArray::getFP actually return a ConstantDataArrayJustin Bogner2015-12-091-1/+1
| | | | | | | | | | The ConstantDataArray::getFP(LLVMContext &, ArrayRef<uint16_t>) overload has had a typo in it since it was written, where it will create a Vector instead of an Array. This obviously doesn't work at all, but it turns out that until r254991 there weren't actually any callers of this overload. Fix the typo and add some test coverage. llvm-svn: 255157
* [PGO] Resubmit "MST based PGO instrumentation infrastructure" (r254021)Rong Xu2015-12-091-0/+6
| | | | | | | | | | | | | | | This new patch fixes a few bugs that exposed in last submit. It also improves the test cases. --Original Commit Message-- This patch implements a minimum spanning tree (MST) based instrumentation for PGO. The use of MST guarantees minimum number of CFG edges getting instrumented. An addition optimization is to instrument the less executed edges to further reduce the instrumentation overhead. The patch contains both the instrumentation and the use of the profile to set the branch weights. Differential Revision: http://reviews.llvm.org/D12781 llvm-svn: 255132
* Don't drop attributes when inlining through "deopt" operand bundlesSanjoy Das2015-12-091-0/+2
| | | | | | | Test case attached (test case also checks that we don't drop the calling convention, but that functionality was correct before this patch). llvm-svn: 255088
* IR: Allow vectors of halfs to be ConstantDataVectorsJustin Bogner2015-12-081-3/+15
| | | | | | | | Currently, vectors of halfs end up as ConstantVectors, but there isn't a good reason they can't be ConstantDataVectors. This should save some memory. llvm-svn: 254991
* Add Instruction::getFunction; NFCSanjoy Das2015-12-081-0/+5
| | | | | | Will be used in a upcoming patch. llvm-svn: 254975
* Remove debug output that snuck into 254957Philip Reames2015-12-071-6/+0
| | | | llvm-svn: 254960
* Reapply 254950 w/fixPhilip Reames2015-12-071-0/+6
| | | | | | | | | | | | | | | | | 254950 ended up being not NFC. The previous code was overriding the flags for whether an instruction read or wrote memory using the target specific flags returned via TTI. I'd missed this in my refactoring. Since I mistakenly built only x86 and didn't notice the number of unsupported tests, I didn't catch that before the original checkin. This raises an interesting issue though. Given we have function attributes (i.e. readonly, readnone, argmemonly) which describe the aliasing of intrinsics, why does TTI have this information overriding the instruction definition at all? I see no reason for this, but decided to preserve existing behavior for the moment. The root issue might be that we don't have a "writeonly" attribute. Original commit message: [EarlyCSE] Simplify and invert ParseMemoryInst [NFCI] Restructure ParseMemoryInst - which was introduced to abstract over target specific load and stores instructions - to just query the underlying instructions. In theory, this could be slightly slower than caching the results, but in practice, it's very unlikely to be measurable. The simple query scheme makes it far easier to understand, and much easier to extend with new queries. Given I'm about to need to add new query types, doing the cleanup first seemed worthwhile. Do we still believe the target specific intrinsic handling is worthwhile in EarlyCSE? It adds quite a bit of complexity and makes the code harder to read. Being able to delete the abstraction entirely would be wonderful. llvm-svn: 254957
* [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
* [PassManager] Ensure destructors of cached AnalysisUsage objects are runPhilip Reames2015-12-041-1/+1
| | | | | | In 254760, I introduced the usage of a BumpPtrAllocator for the AnalysisUsage instances held by the PassManger. This turns out to have been incorrect since a BumpPtrAllocator does not run the destructors of objects when deallocating memory. Since a few of our SmallVector's had grown beyond their small size, we end up with some leaked memory. We need to use a SpecificBumpPtrAllocator instead. llvm-svn: 254803
* [OperandBundles] Allow operand-specific attributes in operand bundlesSanjoy Das2015-12-041-2/+2
| | | | | | | | | | | | | Currently `OperandBundleUse::operandsHaveAttr` computes its result without being given a specific operand. This is problematic because it forces us to say that, e.g., even non-pointer operands in `"deopt"` operand bundles are `readonly`, which doesn't make sense. This commit changes `operandsHaveAttr` to work in the context of a specific operand, so that we can give the operand attributes that make sense for the operands's `llvm::Type`. llvm-svn: 254764
* [LegacyPassManager] Reduce memory usage for AnalysisUsagePhilip Reames2015-12-041-8/+24
| | | | | | | | | | The LegacyPassManager was storing an instance of AnalysisUsage for each instance of each pass. In practice, most instances of a single pass class share the same dependencies. We can't rely on this because passes can (and some do) have dynamic dependencies based on instance options. We can exploit the likely commonality by uniqueing the usage information after querying the pass, but before storing it into the pass manager. This greatly reduces memory consumption by the AnalysisUsage objects. For a long pass pipeline, I measured a decrease in memory consumption for this storage of about 50%. I have not measured on the default O3 pipeline, but I suspect it will see some benefit as well since many passes are repeated (e.g. InstCombine). Differential Revision: http://reviews.llvm.org/D14677 llvm-svn: 254760
* [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
* Interface to attach maximum function count from PGO to module as module flags.Easwaran Raman2015-12-031-0/+12
| | | | | | | | | | This provides interface to get and set maximum function counts to Module. This would allow things like determination of function hotness. The actual setting of this max function count will have to be done in the frontend. Differential Revision: http://reviews.llvm.org/D15003 llvm-svn: 254647
* Don't copy information from aliasee to alias.Rafael Espindola2015-12-022-14/+17
| | | | | | They are independent. llvm-svn: 254541
* [AttributeSet] Overload AttributeSet::addAttribute to reduce compileAkira Hatanaka2015-12-021-0/+30
| | | | | | | | | | | | | | | | | | | | time. The new overloaded function is used when an attribute is added to a large number of slots of an AttributeSet (for example, to function parameters). This is much faster than calling AttributeSet::addAttribute once per slot, because AttributeSet::getImpl (which calls FoldingSet::FIndNodeOrInsertPos) is called only once per function instead of once per slot. With this commit, clang compiles a file which used to take over 22 minutes in just 13 seconds. rdar://problem/23581000 Differential Revision: http://reviews.llvm.org/D15085 llvm-svn: 254491
* IR: Clean up some duplicated code in ConstantDataSequential creation. NFCJustin Bogner2015-12-011-136/+57
| | | | | | | | ConstantDataArray::getImpl and ConstantDataVector::getImpl had a lot of copy pasta in how they handled sequences of constants. Break that out into a couple of simple functions. llvm-svn: 254456
* [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
* [PGO] Revert revision r254021,r254028,r254035Rong Xu2015-11-241-6/+0
| | | | | | Revert the above revision due to multiple issues. llvm-svn: 254040
* [PGO] MST based PGO instrumentation infrastructureRong Xu2015-11-241-0/+6
| | | | | | | | | | | | This patch implements a minimum spanning tree (MST) based instrumentation for PGO. The use of MST guarantees minimum number of CFG edges getting instrumented. An addition optimization is to instrument the less executed edges to further reduce the instrumentation overhead. The patch contains both the instrumentation and the use of the profile to set the branch weights. Differential Revision: http://reviews.llvm.org/D12781 llvm-svn: 254021
* Add vector types for intrinsicsKrzysztof Parzyszek2015-11-241-1/+11
| | | | | Author: Ron Lieberman <ronl@codeaurora.org> llvm-svn: 253992
* Add new vector types for 512-, 1024- and 2048-bit vectorsKrzysztof Parzyszek2015-11-241-0/+22
| | | | | | | | Those types are needed to implement instructions for Hexagon Vector Extensions (HVX): 16x32, 16x64, 32x16, 32x32, 32x64, 64x8, 64x16, 64x32, 128x8, 128x16, 256x8, 512x1, and 1024x1. llvm-svn: 253978
* Revert r253923.Krzysztof Parzyszek2015-11-231-22/+0
| | | | | | Per Eric's request. llvm-svn: 253928
* Add new vector types for 512-, 1024- and 2048-bit vectorsKrzysztof Parzyszek2015-11-231-0/+22
| | | | | | | | Those types are needed to implement instructions for Hexagon Vector Extensions (HVX): 16x32, 16x64, 32x16, 32x32, 32x64, 64x8, 64x16, 64x32, 128x8, 128x16, 256x8, 512x1, and 1024x1. llvm-svn: 253923
* [MDBuilder] Simplify code using initializer lists. NFC.Benjamin Kramer2015-11-221-28/+16
| | | | llvm-svn: 253826
* Have a single way for creating unique value names.Rafael Espindola2015-11-221-29/+21
| | | | | | | | | | | We had two code paths. One would create names like "foo.1" and the other names like "foo1". For globals it is important to use "foo.1" to help C++ name demangling. For locals there is no strong reason to go one way or the other so I kept the most common mangling (foo1). llvm-svn: 253804
* [ThinLTO] Handle bitcode without function summary sections gracefullyTeresa Johnson2015-11-211-0/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: Several fixes to the handling of bitcode files without function summary sections so that they are skipped during ThinLTO processing in llvm-lto and the gold plugin when appropriate instead of aborting. 1 Don't assert when trying to add a FunctionInfo that doesn't have a summary attached. 2 Skip FunctionInfo structures that don't have attached function summary sections when trying to create the combined function summary. 3 In both llvm-lto and gold-plugin, check whether a bitcode file has a function summary section before trying to parse the index, and skip the bitcode file if it does not. 4 Fix hasFunctionSummaryInMemBuffer in BitcodeReader, which had a bug where we returned to early while looking for the summary section. Also added llvm-lto and gold-plugin based tests for cases where we don't have function summaries in the bitcode file. I verified that either the first couple fixes described above are enough to avoid the crashes, or fixes 1,3,4. But have combined them all here for added robustness. Reviewers: joker.eph Subscribers: llvm-commits, joker.eph Differential Revision: http://reviews.llvm.org/D14903 llvm-svn: 253796
* Fix another infinite loop in Reassociate caused by Constant::isZero().Owen Anderson2015-11-201-0/+10
| | | | | | Not all zero vectors are ConstantDataVector's. llvm-svn: 253723
* Fix a pair of issues that caused an infinite loop in reassociate.Owen Anderson2015-11-201-0/+6
| | | | | | | | Terrifyingly, one of them is a mishandling of floating point vectors in Constant::isZero(). How exactly this issue survived this long is beyond me. llvm-svn: 253655
* Pointers in Masked Load, Store, Gather, Scatter intrinsicsElena Demikhovsky2015-11-191-1/+4
| | | | | | | | | | The masked intrinsics support all integer and floating point data types. I added the pointer type to this list. Added tests for CodeGen and for Loop Vectorizer. Updated the Language Reference. Differential Revision: http://reviews.llvm.org/D14150 llvm-svn: 253544
* Revert "Change memcpy/memset/memmove to have dest and source alignments."Pete Cooper2015-11-194-75/+12
| | | | | | | | | | 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-184-12/+75
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Teach the inliner to track deoptimization stateSanjoy Das2015-11-181-0/+26
| | | | | | | | | | | | | | | | Summary: This change teaches LLVM's inliner to track and suitably adjust deoptimization state (tracked via deoptimization operand bundles) as it inlines through call sites. The operation is described in more detail in the LangRef changes. Reviewers: reames, majnemer, chandlerc, dexonsmith Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D14552 llvm-svn: 253438
* Drop prelink support.Rafael Espindola2015-11-171-16/+11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The way prelink used to work was * The compiler decides if a given section only has relocations that are know to point to the same DSO. If so, it names it .data.rel.ro.local<something>. * The static linker puts all of these together. * The prelinker program assigns addresses to each library and resolves the local relocations. There are many problems with this: * It is incompatible with address space randomization. * The information passed by the compiler is redundant. The linker knows if a given relocation is in the same DSO or not. If could sort by that if so desired. * There are newer ways of speeding up DSO (gnu hash for example). * Even if we want to implement this again in the compiler, the previous implementation is pretty broken. It talks about relocations that are "resolved by the static linker". If they are resolved, there are none left for the prelinker. What one needs to track is if an expression will require only dynamic relocations that point to the same DSO. At this point it looks like the prelinker is an historical curiosity. For example, fedora has retired it because it failed to build for two releases (http://pkgs.fedoraproject.org/cgit/prelink.git/commit/?id=eb43100a8331d91c801ee3dcdb0a0bb9babfdc1f) This patch removes support for it. That is, it stops printing the ".local" sections. llvm-svn: 253280
* [IR] Manage TheNoneToken with a std::unique_ptrDavid Majnemer2015-11-163-4/+3
| | | | | | Hopefully, this will make the sanitizer build bots happy. llvm-svn: 253248
* [DIBuilder] Make createReferenceType take size and alignKeno Fischer2015-11-161-2/+4
| | | | | | | | | | | | | | | | | | Summary: Since we're passing references to dbg.value as pointers, we need to have the frontend properly declare their sizes and alignments (as it already does for regular pointers) in preparation for my upcoming patch to have the verifer check that the sizes agree. Also augment the backend logic that skips actually emitting this information into DWARF such that it also handles reference types. Reviewers: aprantl, dexonsmith, dblaikie Subscribers: dblaikie, llvm-commits Differential Revision: http://reviews.llvm.org/D14275 llvm-svn: 253186
* 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
* Revert r252990.Akira Hatanaka2015-11-134-100/+1
| | | | | | Some of the buildbots are still failing. llvm-svn: 252999
* Provide a way to specify inliner's attribute compatibility and merging.Akira Hatanaka2015-11-134-1/+100
| | | | | | | | | | | | | | | | | | This reapplies r252949. I've changed the type of FuncName to be std::string instead of StringRef in emitFnAttrCompatCheck. Original commit message for r252949: Provide a way to specify inliner's attribute compatibility and merging rules using table-gen. NFC. This commit adds new classes CompatRule and MergeRule to Attributes.td, which are used to generate code to check attribute compatibility and merge attributes of the caller and callee. rdar://problem/19836465 llvm-svn: 252990
* Revert r252949.Akira Hatanaka2015-11-124-100/+1
| | | | | | It broke some of the bots including clang-x64-ninja-win7. llvm-svn: 252951
* Provide a way to specify inliner's attribute compatibility and mergingAkira Hatanaka2015-11-124-1/+100
| | | | | | | | | | | | rules using table-gen. NFC. This commit adds new classes CompatRule and MergeRule to Attributes.td, which are used to generate code to check attribute compatibility and merge attributes of the caller and callee. rdar://problem/19836465 llvm-svn: 252949
* Comment update. NFC.Rafael Espindola2015-11-121-16/+0
| | | | | | | | Fix the library name. Don't duplicate the comment in the .cpp file. Don't repeat the name in the comment. llvm-svn: 252911
* [IR] Add support for empty tokensDavid Majnemer2015-11-114-2/+30
| | | | | | | | | | | | | | 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
* Introduce deoptimization operand bundlesSanjoy Das2015-11-112-0/+14
| | | | | | | | | | | | | | | | | | | | | 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
* Move the enum attributes defined in Attributes.h to a table-gen file.Akira Hatanaka2015-11-111-1/+17
| | | | | | | | | | | | | | This is a step towards consolidating some of the information regarding attributes in a single place. This patch moves the enum attributes in Attributes.h to the table-gen file. Additionally, it adds definitions of target independent string attributes that will be used in follow-up commits by the inliner to check attribute compatibility. rdar://problem/19836465 llvm-svn: 252796
OpenPOWER on IntegriCloud