summaryrefslogtreecommitdiff
path: root/include
Commit message (Collapse)AuthorAge
* Allow vectorization of bit intrinsics in BB Vectorizer.Karthik Bhat2014-04-25
| | | | | | | | This patch adds support for vectorization of bit intrinsics such as bswap,ctpop,ctlz,cttz. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@207174 91177308-0d34-0410-b5e6-96231b3b80d8
* Revert "This reapplies r207130 with an additional testcase+and a missing ↵Adrian Prantl2014-04-25
| | | | | | | | check for" Typo in testcase. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@207166 91177308-0d34-0410-b5e6-96231b3b80d8
* This reapplies r207130 with an additional testcase+and a missing check forAdrian Prantl2014-04-25
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | AllocaInst that was missing in one location. Debug info for optimized code: Support variables that are on the stack and described by DBG_VALUEs during their lifetime. Previously, when a variable was at a FrameIndex for any part of its lifetime, this would shadow all other DBG_VALUEs and only a single fbreg location would be emitted, which in fact is only valid for a small range and not the entire lexical scope of the variable. The included dbg-value-const-byref testcase demonstrates this. This patch fixes this by Local - emitting dbg.value intrinsics for allocas that are passed by reference - dropping all dbg.declares (they are now fully lowered to dbg.values) SelectionDAG - renamed constructors for SDDbgValue for better readability. - fix UserValue::match() to handle indirect values correctly - not inserting an MMI table entries for dbg.values that describe allocas. - lowering dbg.values that describe allocas into *indirect* DBG_VALUEs. CodeGenPrepare - leaving dbg.values for an alloca were they are (see comment) Other - regenerated/updated instcombine.ll testcase and included source rdar://problem/16679879 http://reviews.llvm.org/D3374 git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@207165 91177308-0d34-0410-b5e6-96231b3b80d8
* Revert "Debug info for optimized code: Support variables that are on the ↵Adrian Prantl2014-04-25
| | | | | | | | stack and" This reverts commit 207130 for buildbot breakage. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@207162 91177308-0d34-0410-b5e6-96231b3b80d8
* Add missing include, found by modules build.Richard Smith2014-04-24
| | | | git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@207158 91177308-0d34-0410-b5e6-96231b3b80d8
* Function defined in a header should be inline. Found by modules build.Richard Smith2014-04-24
| | | | git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@207157 91177308-0d34-0410-b5e6-96231b3b80d8
* [ADT] Generalize pointee_iterator to smart pointers by using decltype.Chandler Carruth2014-04-24
| | | | | | Based on review feedback from Dave on the original patch. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@207146 91177308-0d34-0410-b5e6-96231b3b80d8
* Remove dead inline function that doesn't compileReid Kleckner2014-04-24
| | | | | | MSVC doesn't diagnose this, interestingly. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@207144 91177308-0d34-0410-b5e6-96231b3b80d8
* Add 'musttail' marker to call instructionsReid Kleckner2014-04-24
| | | | | | | | | | | | This is similar to the 'tail' marker, except that it guarantees that tail call optimization will occur. It also comes with convervative IR verification rules that ensure that tail call optimization is possible. Reviewers: nicholas Differential Revision: http://llvm-reviews.chandlerc.com/D3240 git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@207143 91177308-0d34-0410-b5e6-96231b3b80d8
* [modules] "Specialize" a function by actually specializing a function templateRichard Smith2014-04-24
| | | | | | | | rather than by adding an overload and hoping that it's declared before the code that calls it. (In a modules build, it isn't.) git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@207133 91177308-0d34-0410-b5e6-96231b3b80d8
* Debug info for optimized code: Support variables that are on the stack andAdrian Prantl2014-04-24
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | described by DBG_VALUEs during their lifetime. Previously, when a variable was at a FrameIndex for any part of its lifetime, this would shadow all other DBG_VALUEs and only a single fbreg location would be emitted, which in fact is only valid for a small range and not the entire lexical scope of the variable. The included dbg-value-const-byref testcase demonstrates this. This patch fixes this by Local - emitting dbg.value intrinsics for allocas that are passed by reference - dropping all dbg.declares (they are now fully lowered to dbg.values) SelectionDAG - renamed constructors for SDDbgValue for better readability. - fix UserValue::match() to handle indirect values correctly - not inserting an MMI table entries for dbg.values that describe allocas. - lowering dbg.values that describe allocas into *indirect* DBG_VALUEs. CodeGenPrepare - leaving dbg.values for an alloca were they are (see comment) Other - regenerated/updated instcombine-intrinsics testcase and included source rdar://problem/16679879 http://reviews.llvm.org/D3374 git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@207130 91177308-0d34-0410-b5e6-96231b3b80d8
* [X86] Add support for Read Time Stamp Counter x86 builtin intrinsics.Andrea Di Biagio2014-04-24
| | | | | | | | | | | | | | | | This patch: - Adds two new X86 builtin intrinsics ('int_x86_rdtsc' and 'int_x86_rdtscp') as GCCBuiltin intrinsics; - Teaches the backend how to lower the two new builtins; - Introduces a common function to lower READCYCLECOUNTER dag nodes and the two new rdtsc/rdtscp intrinsics; - Improves (and extends) the existing x86 test 'rdtsc.ll'; now test 'rdtsc.ll' correctly verifies that both READCYCLECOUNTER and the two new intrinsics work fine for both 64bit and 32bit Subtargets. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@207127 91177308-0d34-0410-b5e6-96231b3b80d8
* Spread some const around for non-mutating uses of MCSymbolData.David Blaikie2014-04-24
| | | | | | | | I discovered this const-hole while attempting to coalesnce the Symbol and SymbolMap data structures. There's some pending issues with that, but I figured this change was easy to flush early. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@207124 91177308-0d34-0410-b5e6-96231b3b80d8
* [LCG] Incorporate the core trick of improvements on the naive Tarjan'sChandler Carruth2014-04-24
| | | | | | | | | | | | | | | | | | | | | | | | | | | algorithm here: http://dl.acm.org/citation.cfm?id=177301. The idea of isolating the roots has even more relevance when using the stack not just to implement the DFS but also to implement the recursive step. Because we use it for the recursive step, to isolate the roots we need to maintain two stacks: one for our recursive DFS walk, and another of the nodes that have been walked. The nice thing is that the latter will be half the size. It also fixes a complete hack where we scanned backwards over the stack to find the next potential-root to continue processing. Now that is always the top of the DFS stack. While this is a really nice improvement already (IMO) it further opens the door for two important simplifications: 1) De-duplicating some of the code across the two different walks. I've actually made the duplication a bit worse in some senses with this patch because the two are starting to converge. 2) Dramatically simplifying the loop structures of both walks. I wanted to do those separately as they'll be essentially *just* CFG restructuring. This patch on the other hand actually uses different datastructures to implement the algorithm itself. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@207098 91177308-0d34-0410-b5e6-96231b3b80d8
* [LCG] Switch the parent SCC tracking from a SmallSetVector toChandler Carruth2014-04-24
| | | | | | | | | | | | | | | | a SmallPtrSet. Currently, there is no need for stable iteration in this dimension, and I now thing there won't need to be going forward. If this is ever re-introduced in any form, it needs to not be a SetVector based solution because removal cannot be linear. There will be many SCCs with large numbers of parents. When encountering these, the incremental SCC update for intra-SCC edge removal was quadratic due to linear removal (kind of). I'm really hoping we can avoid having an ordering property here at all though... git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@207091 91177308-0d34-0410-b5e6-96231b3b80d8
* [LCG] We don't actually need a set in each SCC to track the nodes. WeChandler Carruth2014-04-24
| | | | | | | can use the node -> SCC mapping in the top-level graph to test this on the rare occasions we need it. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@207090 91177308-0d34-0410-b5e6-96231b3b80d8
* [LCG] Switch the SCC's parent iterators to be value iterators ratherChandler Carruth2014-04-24
| | | | | | than pointer iterators. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@207086 91177308-0d34-0410-b5e6-96231b3b80d8
* [ADT] Attempt to appease another MSVC oddity by moving the injectedChandler Carruth2014-04-24
| | | | | | class name usage into a context we can put typename on it. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@207084 91177308-0d34-0410-b5e6-96231b3b80d8
* [C++] Use 'nullptr'.Craig Topper2014-04-24
| | | | git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@207083 91177308-0d34-0410-b5e6-96231b3b80d8
* [ADT] Try to appease MSVC by sinking the enable_if from a defaultChandler Carruth2014-04-24
| | | | | | template argument to a default argument to the constructor. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@207082 91177308-0d34-0410-b5e6-96231b3b80d8
* Use the shiny new iterator adaptor tool to implement theChandler Carruth2014-04-24
| | | | | | value_op_iterator. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@207078 91177308-0d34-0410-b5e6-96231b3b80d8
* [ADT] Factor out the facade aspect of the iterator_adaptor_base into itsChandler Carruth2014-04-24
| | | | | | | | | own CRTP base class for more general purpose use. Add some clarifying comments for the exact way in which the adaptor uses it. Hopefully this will help us write increasingly full featured iterators. This is becoming important as they start to be used heavily inside of ranges. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@207072 91177308-0d34-0410-b5e6-96231b3b80d8
* [ADT] Add a generic iterator utility for adapting iterators much likeChandler Carruth2014-04-24
| | | | | | | | | | | | | | | | | | | | | | | | | Boost's iterator_adaptor, and a specific adaptor which iterates over pointees when wrapped around an iterator over pointers. This is the result of a long discussion on IRC with Duncan Smith, Dave Blaikie, Richard Smith, and myself. Essentially, I could use some subset of the iterator facade facilities often used from Boost, and everyone seemed interested in having the functionality in a reasonably generic form. I've tried to strike a balance between the pragmatism and the established Boost design. The primary differences are: 1) Delegating to the standard iterator interface names rather than special names that then make up a second iterator-like API. 2) Using the name 'pointee_iterator' which seems more clear than 'indirect_iterator'. The whole business of calling the '*p' operation 'pointer indirection' in the standard is ... quite confusing. And 'dereference' is no better of a term for moving from a pointer to a reference. Hoping Duncan, and others continue to provide comments on this until we've got a nice, minimal abstraction. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@207069 91177308-0d34-0410-b5e6-96231b3b80d8
* [LCG] Normalize the post-order SCC iterator to just iterate over the SCCChandler Carruth2014-04-23
| | | | | | values rather than having pointers in weird places. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@207053 91177308-0d34-0410-b5e6-96231b3b80d8
* [LCG] Remove two unused typedefs from the iterators.Chandler Carruth2014-04-23
| | | | git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@207052 91177308-0d34-0410-b5e6-96231b3b80d8
* [LCG] Switch the primary node iterator to be a *much* more normal C++Chandler Carruth2014-04-23
| | | | | | iterator, returning a Node by reference on dereference. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@207048 91177308-0d34-0410-b5e6-96231b3b80d8
* [LCG] Make the insertion and query paths into the LCG which cannot failChandler Carruth2014-04-23
| | | | | | | | return references to better model this property. No functionality changed. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@207047 91177308-0d34-0410-b5e6-96231b3b80d8
* [LCG] Switch the SCC lookup to be in terms of call graph nodes ratherChandler Carruth2014-04-23
| | | | | | | | | | than functions. So far, this access pattern is *much* more common. It seems likely that any user of this interface is going to have nodes at the point that they are querying the SCCs. No functionality changed. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@207045 91177308-0d34-0410-b5e6-96231b3b80d8
* Use std::less instead of < in array_pod_sort's default comparator.Jordan Rose2014-04-23
| | | | | | This makes array_pod_sort portably safe to use with pointers. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@207043 91177308-0d34-0410-b5e6-96231b3b80d8
* llvm-cov: Add support for gcov's --long-file-names optionJustin Bogner2014-04-23
| | | | | | | | GCOV provides an option to prepend output file names with the source file name, to disambiguate between covered data that's included from multiple sources. Add a flag to llvm-cov that does the same. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@207035 91177308-0d34-0410-b5e6-96231b3b80d8
* Remove AssemblyAnnotationWriter from NamedMDNode::print.Rafael Espindola2014-04-23
| | | | | | | | No functionality change, this parameter was always set to nullptr. Patch by Robert Matusewicz! git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@206972 91177308-0d34-0410-b5e6-96231b3b80d8
* Create MCTargetOptions.Evgeniy Stepanov2014-04-23
| | | | | | | | | | For now it contains a single flag, SanitizeAddress, which enables AddressSanitizer instrumentation of inline assembly. Patch by Yuri Gorshenin. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@206971 91177308-0d34-0410-b5e6-96231b3b80d8
* [yaml2obj][ELF] Add a virtual destructor to the ELFYAML::Section classSimon Atanasyan2014-04-23
| | | | | | to prevent memory leaks. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@206969 91177308-0d34-0410-b5e6-96231b3b80d8
* [LCG] Add the first round of mutation support to the lazy call graph.Chandler Carruth2014-04-23
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | This implements the core functionality necessary to remove an edge from the call graph and correctly update both the basic graph and the SCC structure. As part of that it has to run a tiny (in number of nodes) Tarjan-style DFS walk of an SCC being mutated to compute newly formed SCCs, etc. This is *very rough* and a WIP. I have a bunch of FIXMEs for code cleanup that will reduce the boilerplate in this change substantially. I also have a bunch of simplifications to various parts of both algorithms that I want to make, but first I'd like to have a more holistic picture. Ideally, I'd also like more testing. I'll probably add quite a few more unit tests as I go here to cover the various different aspects and corner cases of removing edges from the graph. Still, this is, so far, successfully updating the SCC graph in-place without disrupting the identity established for the existing SCCs even when we do challenging things like delete the critical edge that made an SCC cycle at all and have to reform things as a tree of smaller SCCs. Getting this to work is really critical for the new pass manager as it is going to associate significant state with the SCC instance and needs it to be stable. That is also the motivation behind the return of the newly formed SCCs. Eventually, I'll wire this all the way up to the public API so that the pass manager can use it to correctly re-enqueue newly formed SCCs into a fresh postorder traversal. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@206968 91177308-0d34-0410-b5e6-96231b3b80d8
* [LCG] Implement Tarjan's algorithm correctly this time. We have to walkChandler Carruth2014-04-23
| | | | | | | | | | | | up the stack finishing the exploration of each entries children before we're finished in addition to accounting for their low-links. Added a unittest that really hammers home the need for this with interlocking cycles that would each appear distinct otherwise and crash or compute the wrong result. As part of this, nuke a stale fixme and bring the rest of the implementation still more closely in line with the original algorithm. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@206966 91177308-0d34-0410-b5e6-96231b3b80d8
* [LCG] Add some accessor methods to the SCC to allow iterating over theChandler Carruth2014-04-23
| | | | | | | | | parents of an SCC, and add a lookup method for finding the SCC for a given function. These aren't used yet, but will be used shortly in some unit tests I'm adding and are really part of the broader intended interface for the analysis. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@206959 91177308-0d34-0410-b5e6-96231b3b80d8
* [LCG] Add a unittest for the LazyCallGraph. I had a weak moment andChandler Carruth2014-04-23
| | | | | | | | | | | | | | | | | | | | | | | | resisted this for too long. Just with the basic testing here I was able to exercise the analysis in more detail and sift out both type signature bugs in the API and a bug in the DFS numbering. All of these are fixed here as well. The unittests will be much more important for the mutation support where it is necessary to craft minimal mutations and then inspect the state of the graph. There is just no way to do that with a standard FileCheck test. However, unittesting these kinds of analyses is really quite easy, especially as they're designed with the new pass manager where there is essentially no infrastructure required to rig up the core logic and exercise it at an API level. As a minor aside about the DFS numbering bug, the DFS numbering used in LCG is a bit unusual. Rather than numbering from 0, we number from 1, and use 0 as the sentinel "unvisited" state. Other implementations often use '-1' for this, but I find it easier to deal with 0 and it shouldn't make any real difference provided someone doesn't write silly bugs like forgetting to actually initialize the DFS numbering. Oops. ;] git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@206954 91177308-0d34-0410-b5e6-96231b3b80d8
* [LCG] Hoist the logic for forming a new SCC from the top of the DFSStackChandler Carruth2014-04-23
| | | | | | | into a helper function. I plan to re-use it for doing incremental DFS-based updates to the SCCs when we mutate the call graph. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@206948 91177308-0d34-0410-b5e6-96231b3b80d8
* [LCG] Switch the Callee sets to be DenseMaps pointing to the index intoChandler Carruth2014-04-23
| | | | | | | | | the Callee list. This is going to be quite important to prevent removal from going quadratic. No functionality changed at this point, this is one of the refactoring patches I've broken out of my initial work toward mutation updates of the call graph. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@206938 91177308-0d34-0410-b5e6-96231b3b80d8
* Change the prototype for MCContext::FatalError() so it can be calledKevin Enderby2014-04-22
| | | | | | | | | | | from places like MCCodeEmitter() in the MC backend when the MCContext is const. I was going to use this in my change for r206669 but Jim convinced me to use an assert there. But this still is a good tweak. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@206923 91177308-0d34-0410-b5e6-96231b3b80d8
* WhitespaceRui Ueyama2014-04-22
| | | | git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@206919 91177308-0d34-0410-b5e6-96231b3b80d8
* No need to check condition after grow()Rui Ueyama2014-04-22
| | | | | | | | | | r206916 was not logically the same as the previous code because the goto statements did not create loop. This should be the same as the previous code. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@206918 91177308-0d34-0410-b5e6-96231b3b80d8
* Replace loops using goto with plain while loopsRui Ueyama2014-04-22
| | | | | | | | | | Goto statements jumping into previous inner blocks are pretty confusing to read even though in this case they are valid. No reason to not use while loops there. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@206916 91177308-0d34-0410-b5e6-96231b3b80d8
* Fix the assembler to print a better relocatable expression errorKevin Enderby2014-04-22
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | diagnostic that includes location information. Currently if one has this assembly: .quad (0x1234 + (4 * SOME_VALUE)) where SOME_VALUE is undefined ones gets the less than useful error message with no location information: % clang -c x.s clang -cc1as: fatal error: error in backend: expected relocatable expression With this fix one now gets a more useful error message with location information: % clang -c x.s x.s:5:8: error: expected relocatable expression .quad (0x1234 + (4 * SOME_VALUE)) ^ To do this I plumbed the SMLoc through the MCObjectStreamer EmitValue() and EmitValueImpl() interfaces so it could be used when creating the MCFixup. rdar://12391022 git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@206906 91177308-0d34-0410-b5e6-96231b3b80d8
* AArch64/ARM64: mark fmul intrinsic as commutative.Tim Northover2014-04-22
| | | | | | | This gives DAG patterns matching indexed patterns where either side is an indexed vector. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@206875 91177308-0d34-0410-b5e6-96231b3b80d8
* blockfreq: Rename PackagedLoops => LoopsDuncan P. N. Exon Smith2014-04-22
| | | | git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@206859 91177308-0d34-0410-b5e6-96231b3b80d8
* blockfreq: Use a pointer for ContainingLoop tooDuncan P. N. Exon Smith2014-04-22
| | | | git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@206858 91177308-0d34-0410-b5e6-96231b3b80d8
* blockfreq: Use pointers to loops instead of an indexDuncan P. N. Exon Smith2014-04-22
| | | | | | | | | | | | | Store pointers directly to loops inside the nodes. This could have been done without changing the type stored in `std::vector<>`. However, rather than computing the number of loops before constructing them (which `LoopInfo` doesn't provide directly), I've switched to a `vector<unique_ptr<LoopData>>`. This adds some heap overhead, but the number of loops is typically small. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@206857 91177308-0d34-0410-b5e6-96231b3b80d8
* blockfreq: Rename PackagedLoopData => LoopDataDuncan P. N. Exon Smith2014-04-22
| | | | | | No functionality change. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@206855 91177308-0d34-0410-b5e6-96231b3b80d8
* blockfreq: Move PackagedLoopData above WorkingDataDuncan P. N. Exon Smith2014-04-22
| | | | git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@206854 91177308-0d34-0410-b5e6-96231b3b80d8
generated by cgit v1.2.3 (git 2.25.1) at 2024-04-29 19:27:45 +0000