summaryrefslogtreecommitdiffstats
Commit message (Collapse)AuthorAgeFilesLines
...
* GPGPU: Bail out gracefully in case of invalid IRTobias Grosser2016-09-122-4/+91
| | | | | | | | | | | Instead of aborting, we now bail out gracefully in case the kernel IR we generate is invalid. This can currently happen in case the SCoP stores pointer values, which we model as arrays, as data values into other arrays. In this case, the original pointer value is not available on the device and can consequently not be stored. As detecting this ahead of time is not so easy, we detect these situations after the invalid IR has been generated and bail out. llvm-svn: 281193
* Add a mode to clang-tblgen to generate reference documentation for warning andRichard Smith2016-09-1210-4/+11061
| | | | | | | | remark flags. For now I'm checking in a copy of the built documentation, but we can replace this with a placeholder (as we do for the attributes reference documentation) once we enable building this server-side. llvm-svn: 281192
* Fix about a dozen compile warningsIlia K2016-09-128-23/+25
| | | | | | | | | | | | | | | | | | | | | | Summary: It fixes the following compile warnings: 1. '0' flag ignored with precision and ‘%d’ gnu_printf format 2. enumeral and non-enumeral type in conditional expression 3. format ‘%d’ expects argument of type ‘int’, but argument 4 has type ... 4. enumeration value ‘...’ not handled in switch 5. cast from type ‘const uint64_t* {aka ...}’ to type ‘int64_t* {aka ...}’ casts away qualifiers 6. extra ‘;’ 7. comparison between signed and unsigned integer expressions 8. variable ‘register_operand’ set but not used 9. control reaches end of non-void function Reviewers: jingham, emaste, zturner, clayborg Subscribers: lldb-commits Differential Revision: https://reviews.llvm.org/D24331 llvm-svn: 281191
* llvm/test/CodeGen/AMDGPU/infinite-loop-evergreen.ll REQUIRES +Asserts.NAKAMURA Takumi2016-09-121-0/+1
| | | | | | This might not *crash* with -Asserts. I saw it caused infinite loop in the codegen. llvm-svn: 281190
* [MS ABI] Add /include directives for dynamic TLSDavid Majnemer2016-09-122-0/+13
| | | | | | | | | MSVC emits /include directives in the .drective section for the __dyn_tls_init function (decorated as ___dyn_tls_init@12 for 32-bit). This fixes PR30347. llvm-svn: 281189
* MC: Move MCSection::begin/end to header, NFCDuncan P. N. Exon Smith2016-09-122-24/+8
| | | | llvm-svn: 281188
* [InstCombine] add helper function for folding {and,or,xor} (cast X), C ; NFCISanjay Patel2016-09-121-28/+41
| | | | llvm-svn: 281187
* [InstCombine] regenerate checksSanjay Patel2016-09-121-52/+55
| | | | llvm-svn: 281186
* [InstCombine] regenerate checksSanjay Patel2016-09-121-98/+108
| | | | llvm-svn: 281185
* ADT: Never allocate nodes in iplist<> and ilist<>Duncan P. N. Exon Smith2016-09-116-109/+75
| | | | | | | | | | | | | | | | | | | | | | | | | | | Remove createNode() and any API that depending on it, and add HasCreateNode to the list of checks for HasObsoleteCustomizations. Now an ilist *never* allocates (this was already true for iplist). This factors out all the differences between iplist and ilist. I'll aim to rename both to "owning_ilist" eventually, to call out the interesting (not exactly intrusive) ownership semantics. In the meantime, I've left both names around to reduce code churn. One of the deleted APIs is the ilist copy constructor. I've lifted up and tested iplist::cloneFrom (ala simple_ilist::cloneFrom) as a replacement. Users of ilist<> and iplist<> that want the list to allocate nodes have a few options: - use std::list; - use AllocatorList or BumpPtrList (or build a similarly trivial list); - use cloneFrom (which is explicit at the call site); or - allocate at the call site. See r280573, r281177, r281181, and r281182 for examples of what to do if you're updating out-of-tree code. llvm-svn: 281184
* ADT: Fix build after r281182Duncan P. N. Exon Smith2016-09-111-4/+4
| | | | | | | | | | Fix this bot: http://lab.llvm.org:8011/builders/clang-x86_64-linux-abi-test/builds/20680 which complained that a typedef of 'iterator_adaptor_base' changed meaning in AllocatorList::IteratorImpl. Use 'base_type' there instead. llvm-svn: 281183
* ADT: Add AllocatorList, and use it for yaml::TokenDuncan P. N. Exon Smith2016-09-116-18/+486
| | | | | | | | | | | | | | | | | | | | | | | | | | | | - Add AllocatorList, a non-intrusive list that owns an LLVM-style allocator and provides a std::list-like interface (trivially built on top of simple_ilist), - add a typedef (and unit tests) for BumpPtrList, and - use BumpPtrList for the list of llvm::yaml::Token (i.e., TokenQueueT). TokenQueueT has no need for the complexity of an intrusive list. The only reason to inherit from ilist was to customize the allocator. TokenQueueT was the only example in-tree of using ilist<> in a truly non-intrusive way. Moreover, this removes the final use of the non-intrusive ilist_traits<>::createNode (after r280573, r281177, and r281181). I have a WIP patch that removes this customization point (and the API that relies on it) that I plan to commit soon. Note: AllocatorList owns the allocator, which limits the viable API (e.g., splicing must be on the same list). For now I've left out any problematic API. It wouldn't be hard to split AllocatorList into two layers: an Impl class that calls DerivedT::getAlloc (via CRTP), and derived classes that handle Allocator ownership/reference/etc semantics; and then implement splice with appropriate assertions; but TBH we should probably just customize the std::list allocators at that point. llvm-svn: 281182
* Analysis: Only allow the move-constructor for IVUsersDuncan P. N. Exon Smith2016-09-112-1/+40
| | | | | | | | | | | | | | | | | Force IVUsers to be moved instead of copied, properly update Parent pointers in IVStrideUse when IVUsers is moved, and make sure we have move constructors available in iplist and ilist. I came across this in a WIP patch that deleted the copy constructors from ilist. I was surprised to find that IVUsersAnalysis couldn't be registered in the new pass manager. It's not clear to me whether IVUsers was getting moved only when empty, but if it was being moved when it was non-empty then this fixes a pointer invalidation bug and should give some sort of speedup. Note that the bugfix would be necessary even for a copy constructor. llvm-svn: 281181
* [TwoAddressInstruction] When commuting an instruction don't assume that the ↵Craig Topper2016-09-111-3/+5
| | | | | | | | destination register is operand 0. Pass it from the caller. In practice it probably is 0 so this may not be a functional change. llvm-svn: 281180
* [libcxx] Introduce an externally-threaded libc++ variant.Asiri Rathnayake2016-09-1115-52/+148
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch further decouples libc++ from pthread, allowing libc++ to be built against other threading systems. There are two main use cases: - Building libc++ against a thread library other than pthreads. - Building libc++ with an "external" thread API, allowing a separate library to provide the implementation of that API. The two use cases are quite similar, the second one being sligtly more de-coupled than the first. The cmake option LIBCXX_HAS_EXTERNAL_THREAD_API enables both kinds of builds. One needs to place an <__external_threading> header file containing an implementation of the "libc++ thread API" declared in the <__threading_support> header. For the second use case, the implementation of the libc++ thread API can delegate to a custom "external" thread API where the implementation of this external API is provided in a seperate library. This mechanism allows toolchain vendors to distribute a build of libc++ with a custom thread-porting-layer API (which is the "external" API above), platform vendors (recipients of the toolchain/libc++) are then required to provide their implementation of this API to be linked with (end-user) C++ programs. Note that the second use case still requires establishing the basic types that get passed between the external thread library and the libc++ library (e.g. __libcpp_mutex_t). These cannot be opaque pointer types (libc++ sources won't compile otherwise). It should also be noted that the second use case can have a slight performance penalty; as all the thread constructs need to cross a library boundary through an additional function call. When the header <__external_threading> is omitted, libc++ is built with the "libc++ thread API" (declared in <__threading_support>) as the "external" thread API (basic types are pthread based). An implementation (pthread based) of this API is provided in test/support/external_threads.cpp, which is built into a separate DSO and linked in when running the libc++ test suite. A test run therefore demonstrates the second use case (less the intermediate custom API). Differential revision: https://reviews.llvm.org/D21968 Reviewers: bcraig, compnerd, EricWF, mclow.lists llvm-svn: 281179
* [ORC] Update examples for header changes in r281171.Lang Hames2016-09-111-2/+2
| | | | llvm-svn: 281178
* ScalarOpts: Use std::list for Candidates, NFCDuncan P. N. Exon Smith2016-09-111-2/+3
| | | | | | | There is nothing intrusive about the Candidate list; use std::list over llvm::ilist for simplicity. llvm-svn: 281177
* ScalarOpts: Sort includes, NFCDuncan P. N. Exon Smith2016-09-111-2/+1
| | | | llvm-svn: 281176
* ADT: Remove ilist_iterator::reset(), NFCDuncan P. N. Exon Smith2016-09-112-3/+1
| | | | | | | | ilist_iterator::reset was unnecessary API, and wasn't any clearer (or safer) at the call site than constructing a temporary and assigning it to the iterator. llvm-svn: 281175
* [ORC] Fix the RPC unit test for header changes in r281171.Lang Hames2016-09-111-2/+2
| | | | llvm-svn: 281173
* CodeGen: Give MachineBasicBlock::reverse_iterator a handle to the current MIDuncan P. N. Exon Smith2016-09-1114-70/+146
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Now that MachineBasicBlock::reverse_instr_iterator knows when it's at the end (since r281168 and r281170), implement MachineBasicBlock::reverse_iterator directly on top of an ilist::reverse_iterator by adding an IsReverse template parameter to MachineInstrBundleIterator. This replaces another hard-to-reason-about use of std::reverse_iterator on list iterators, matching the changes for ilist::reverse_iterator from r280032 (see the "out of scope" section at the end of that commit message). MachineBasicBlock::reverse_iterator now has a handle to the current node and has obvious invalidation semantics. r280032 has a more detailed explanation of how list-style reverse iterators (invalidated when the pointed-at node is deleted) are different from vector-style reverse iterators like std::reverse_iterator (invalidated on every operation). A great motivating example is this commit's changes to lib/CodeGen/DeadMachineInstructionElim.cpp. Note: If your out-of-tree backend deletes instructions while iterating on a MachineBasicBlock::reverse_iterator or converts between MachineBasicBlock::iterator and MachineBasicBlock::reverse_iterator, you'll need to update your code in similar ways to r280032. The following table might help: [Old] ==> [New] delete &*RI, RE = end() delete &*RI++ RI->erase(), RE = end() RI++->erase() reverse_iterator(I) std::prev(I).getReverse() reverse_iterator(I) ++I.getReverse() --reverse_iterator(I) I.getReverse() reverse_iterator(std::next(I)) I.getReverse() RI.base() std::prev(RI).getReverse() RI.base() ++RI.getReverse() --RI.base() RI.getReverse() std::next(RI).base() RI.getReverse() (For more details, have a look at r280032.) llvm-svn: 281172
* [ORC] Rename RPCChannel to RPCByteChannel. NFC.Lang Hames2016-09-116-44/+46
| | | | llvm-svn: 281171
* CodeGen: Assert that bundle iterators are validDuncan P. N. Exon Smith2016-09-113-11/+67
| | | | | | | | | | | | | | | | | | | | | | | | | | Add an assertion to the MachineInstrBundleIterator from instr_iterator that the underlying iterator is valid. This is possible know that we can check ilist_node::isSentinel (since r281168), and is consistent with the constructors from MachineInstr* and MachineInstr&. Avoiding the new assertion in operator== and operator!= requires four (!!!!) new overloads each. (As an aside, I'm strongly in favour of: - making the conversion from instr_iterator explicit; - making the conversion from pointer explicit; - making the conversion from reference explicit; and - removing all the extra overloads of operator== and operator!= except const_instr_iterator. I'm not signing up for that at this point, but being clear about when something is an MachineInstr-iterator (possibly instr_end()) vs MachineInstr-bundle-iterator (possibly end()) vs MachineInstr* (possibly nullptr) vs MachineInstr& (known valid) would surely make code cleaner... and it would remove a ton of boilerplate from MachineInstrBundleIterator operators.) llvm-svn: 281170
* Fix the modules build after r281167Duncan P. N. Exon Smith2016-09-111-0/+2
| | | | | | | Add an #include for <type_traits> to llvm/ADT/ilist_node_options.h to make it standalone. llvm-svn: 281169
* CodeGen: Turn on sentinel tracking for MachineInstr iteratorsDuncan P. N. Exon Smith2016-09-115-11/+15
| | | | | | | | | | | | | | | | | | | | This is a prep commit before fixing MachineBasicBlock::reverse_iterator invalidation semantics, ala r281167 for ilist::reverse_iterator. This changes MachineBasicBlock::Instructions to track which node is the sentinel regardless of LLVM_ENABLE_ABI_BREAKING_CHECKS. There's almost no functionality change (aside from ABI). However, in the rare configuration: #if !defined(NDEBUG) && !defined(LLVM_ENABLE_ABI_BREAKING_CHECKS) the isKnownSentinel() assertions in ilist_iterator<>::operator* suddenly have teeth for MachineInstr. If these assertions start firing for your out-of-tree backend, have a look at the suggestions in the commit message for r279314, and at some of the commits leading up to it that avoid dereferencing the end() iterator. llvm-svn: 281168
* ADT: Add sentinel tracking and custom tags to ilistsDuncan P. N. Exon Smith2016-09-1114-156/+642
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This adds two declarative configuration options for intrusive lists (available for simple_ilist, iplist, and ilist). Both of these options affect ilist_node interoperability and need to be passed both to the node and the list. Instead of adding a new traits class, they're specified as optional template parameters (in any order). The two options: 1. Pass ilist_sentinel_tracking<true> or ilist_sentinel_tracking<false> to control whether there's a bit on ilist_node "prev" pointer indicating whether it's the sentinel. The default behaviour is to use a bit if and only if LLVM_ENABLE_ABI_BREAKING_CHECKS. 2. Pass ilist_tag<TagA> and ilist_tag<TagB> to allow insertion of a single node into two different lists (simultaneously). I have an immediate use-case for (1) ilist_sentinel_tracking: fixing the validation semantics of MachineBasicBlock::reverse_iterator to match ilist::reverse_iterator (ala r280032: see the comments at the end of the commit message there). I'm adding (2) ilist_tag in the same commit to validate that the options framework supports expansion. Justin Bogner mentioned this might enable a possible cleanup in SelectionDAG, but I'll leave this to others to explore. In the meantime, the unit tests and the comments for simple_ilist and ilist_node have usage examples. Note that there's a layer of indirection to support optional, out-of-order, template paramaters. Internal classes are templated on an instantiation of the non-variadic ilist_detail::node_options. User-facing classes use ilist_detail::compute_node_options to compute the correct instantiation of ilist_detail::node_options. The comments for ilist_detail::is_valid_option describe how to add new options (e.g., ilist_packed_int<int NumBits>). llvm-svn: 281167
* Add missing 'REQUIRES' lineTobias Grosser2016-09-111-0/+2
| | | | llvm-svn: 281166
* GPGPU: Do not fail in case of arrays never accessedTobias Grosser2016-09-112-11/+293
| | | | | | | | | If these arrays have never been accessed we failed to derive an upper bound of the accesses and consequently a size for the outermost dimension. We now explicitly check for empty access sets and then just use zero as size for the outermost dimension. llvm-svn: 281165
* [AVX512] Fix pattern for vgetmantsd and all other instructions that use same ↵Igor Breger2016-09-111-8/+1
| | | | | | | | class. Fix memory operand size, remove unnecessary pattern. Differential Revision: http://reviews.llvm.org/D24443 llvm-svn: 281164
* Fixup failing debuginfo test for change in SimplifyCFG.James Molloy2016-09-111-2/+1
| | | | | | This reverts this test back to its original pre-r280364 behaviour as we don't sink allocas any more. llvm-svn: 281163
* [SimplifyCFG] Be even more conservative in SinkThenElseCodeToEndJames Molloy2016-09-113-29/+44
| | | | | | | | This should *actually* fix PR30244. This cranks up the workaround for PR30188 so that we never sink loads or stores of allocas. The idea is that these should be removed by SROA/Mem2Reg, and any movement of them may well confuse SROA or just cause unwanted code churn. It's not ideal that the midend should be crippled like this, but that unwanted churn can really cause significant regressions in important workloads (tsan). llvm-svn: 281162
* [AArch64] Fixup test after r281160James Molloy2016-09-111-1/+1
| | | | | | How I missed this locally is beyond me. I suspect llc didn't recompile. This is just changing the CHECK line back to what it was before r280364. llvm-svn: 281161
* [SimplifyCFG] Harden up the profitability heuristic for block splitting ↵James Molloy2016-09-112-8/+72
| | | | | | | | | | | | during sinking Exposed by PR30244, we will split a block currently if we think we can sink at least one instruction. However this isn't right - the reason we split predecessors is so that we can sink instructions that otherwise couldn't be sunk because it isn't safe to do so - stores, for example. So, change the heuristic to only split if it thinks it can sink at least one non-speculatable instruction. Should fix PR30244. llvm-svn: 281160
* GPURuntime: ensure compilation with C99Tobias Grosser2016-09-111-0/+2
| | | | | | Otherwise, older compiler will error out on some of the C99 features we use. llvm-svn: 281159
* [CodeGen] Make the TwoAddressInstructionPass check if the instruction is ↵Craig Topper2016-09-111-1/+4
| | | | | | commutable before calling findCommutedOpIndices for every operand. Also make sure the operand is a register before each call to save some work on commutable instructions that might have an operand. llvm-svn: 281158
* [AVX-512] Add test cases to demonstrate opportunities for commuting ↵Craig Topper2016-09-111-0/+529
| | | | | | vpternlog. Commuting will be added in a future commit. llvm-svn: 281157
* [AVX-512] Add VPTERNLOG to load folding tables.Craig Topper2016-09-112-0/+36
| | | | llvm-svn: 281156
* [X86] Side effecting asm in AVX512 integer stack folding test should return ↵Craig Topper2016-09-111-20/+20
| | | | | | 2 x i64 not 8 x i64. llvm-svn: 281155
* [X86] Make a helper method into a static function local to the cpp file.Craig Topper2016-09-112-11/+10
| | | | llvm-svn: 281154
* Add handling of !invariant.load to PropagateMetadata.Justin Lebar2016-09-112-6/+23
| | | | | | | | | | | | | | Summary: This will let e.g. the load/store vectorizer propagate this metadata appropriately. Reviewers: arsenm Subscribers: tra, jholewinski, hfinkel, mzolotukhin Differential Revision: https://reviews.llvm.org/D23479 llvm-svn: 281153
* [NVPTX] Use ldg for explicitly invariant loads.Justin Lebar2016-09-112-13/+49
| | | | | | | | | | | | | | | | | | Summary: With this change (plus some changes to prevent !invariant from being clobbered within llvm), clang will be able to model the __ldg CUDA builtin as an invariant load, rather than as a target-specific llvm intrinsic. This will let the optimizer play with these loads -- specifically, we should be able to vectorize them in the load-store vectorizer. Reviewers: tra Subscribers: jholewinski, hfinkel, llvm-commits, chandlerc Differential Revision: https://reviews.llvm.org/D23477 llvm-svn: 281152
* [CodeGen] Split out the notions of MI invariance and MI dereferenceability.Justin Lebar2016-09-1124-70/+112
| | | | | | | | | | | | | | | | | | | Summary: An IR load can be invariant, dereferenceable, neither, or both. But currently, MI's notion of invariance is IR-invariant && IR-dereferenceable. This patch splits up the notions of invariance and dereferenceability at the MI level. It's NFC, so adds some probably-unnecessary "is-dereferenceable" checks, which we can remove later if desired. Reviewers: chandlerc, tstellarAMD Subscribers: jholewinski, arsenm, nemanjai, llvm-commits Differential Revision: https://reviews.llvm.org/D23371 llvm-svn: 281151
* CodeGen: remove unnecessary else caseSaleem Abdulrasool2016-09-111-6/+3
| | | | | | | Refactor the assignment so that its much more clear that the if-clause contains the lookup, and once cached is directly used. NFC. llvm-svn: 281150
* MCInstrDesc: Flags (uint64_t) was checked using (1 << MCID::XYZ), but this Sjoerd Meijer2016-09-101-32/+32
| | | | | | | | | should have been (1ULL << MCID::XYZ). Currently this works because enum Flag has 31 values, but extending it will result in a compile warnings/errors. This was part of the accepted patch in https://reviews.llvm.org/D23601, but it was suggested to apply this first as a separate patch. llvm-svn: 281149
* [MachO] Remove code accidentally cut'n'pasted 3 times.Davide Italiano2016-09-101-204/+0
| | | | | | | It wasn't harmful, just goofy. It's weird to see how this has fallen through the crack without anybody noticing for so long. llvm-svn: 281148
* It should also be legal to pass a swifterror parameter to a call as a swifterrorArnold Schwaighofer2016-09-103-8/+82
| | | | | | | | argument. rdar://28233388 llvm-svn: 281147
* [llvm-cov] Move the 'jump to first unexecuted line' linkVedant Kumar2016-09-107-39/+36
| | | | | | | Having it in the same row as the source name is jarring. Move it next to the "Source" column label. llvm-svn: 281146
* [llvm-cov] Minor visual tweaks for html reportsVedant Kumar2016-09-106-76/+35
| | | | | | | - Change the location of the 'Region Coverage' column. - Use less css and text for some labels. llvm-svn: 281145
* InstCombine: Don't combine loads/stores from swifterror to a new typeArnold Schwaighofer2016-09-103-0/+41
| | | | | | | | | This generates invalid IR: the only users of swifterror can be call arguments, loads, and stores. rdar://28242257 llvm-svn: 281144
* Add an isSwiftError predicate to ValueArnold Schwaighofer2016-09-102-0/+16
| | | | llvm-svn: 281143
OpenPOWER on IntegriCloud