aboutsummaryrefslogtreecommitdiff
path: root/llvm/lib
AgeCommit message (Collapse)AuthorFilesLines
2016-09-12Fix WebAssembly broken build related to interface change in r281172.Eric Liu1-2/+1
Reviewers: bkramer Subscribers: jfb, llvm-commits, dschuff Differential Revision: https://reviews.llvm.org/D24449 llvm-svn: 281201
2016-09-12MC: Move MCSection::begin/end to header, NFCDuncan P. N. Exon Smith1-8/+0
llvm-svn: 281188
2016-09-12[InstCombine] add helper function for folding {and,or,xor} (cast X), C ; NFCISanjay Patel1-28/+41
llvm-svn: 281187
2016-09-11ADT: Add AllocatorList, and use it for yaml::TokenDuncan P. N. Exon Smith1-18/+5
- 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
2016-09-11[TwoAddressInstruction] When commuting an instruction don't assume that the ↵Craig Topper1-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
2016-09-11ScalarOpts: Use std::list for Candidates, NFCDuncan P. N. Exon Smith1-2/+3
There is nothing intrusive about the Candidate list; use std::list over llvm::ilist for simplicity. llvm-svn: 281177
2016-09-11ScalarOpts: Sort includes, NFCDuncan P. N. Exon Smith1-2/+1
llvm-svn: 281176
2016-09-11CodeGen: Give MachineBasicBlock::reverse_iterator a handle to the current MIDuncan P. N. Exon Smith11-51/+30
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
2016-09-11CodeGen: Turn on sentinel tracking for MachineInstr iteratorsDuncan P. N. Exon Smith1-3/+3
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
2016-09-11[AVX512] Fix pattern for vgetmantsd and all other instructions that use same ↵Igor Breger1-8/+1
class. Fix memory operand size, remove unnecessary pattern. Differential Revision: http://reviews.llvm.org/D24443 llvm-svn: 281164
2016-09-11[SimplifyCFG] Be even more conservative in SinkThenElseCodeToEndJames Molloy1-15/+19
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
2016-09-11[SimplifyCFG] Harden up the profitability heuristic for block splitting ↵James Molloy1-5/+20
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
2016-09-11[CodeGen] Make the TwoAddressInstructionPass check if the instruction is ↵Craig Topper1-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
2016-09-11[AVX-512] Add VPTERNLOG to load folding tables.Craig Topper1-0/+18
llvm-svn: 281156
2016-09-11[X86] Make a helper method into a static function local to the cpp file.Craig Topper2-11/+10
llvm-svn: 281154
2016-09-11Add handling of !invariant.load to PropagateMetadata.Justin Lebar1-6/+6
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
2016-09-11[NVPTX] Use ldg for explicitly invariant loads.Justin Lebar1-13/+22
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
2016-09-11[CodeGen] Split out the notions of MI invariance and MI dereferenceability.Justin Lebar22-62/+101
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
2016-09-10It should also be legal to pass a swifterror parameter to a call as a swifterrorArnold Schwaighofer1-4/+9
argument. rdar://28233388 llvm-svn: 281147
2016-09-10InstCombine: Don't combine loads/stores from swifterror to a new typeArnold Schwaighofer1-0/+8
This generates invalid IR: the only users of swifterror can be call arguments, loads, and stores. rdar://28242257 llvm-svn: 281144
2016-09-10Add an isSwiftError predicate to ValueArnold Schwaighofer1-0/+10
llvm-svn: 281143
2016-09-10[InstCombine] clean up foldICmpBinOpEqualityWithConstant / ↵Sanjay Patel1-59/+56
foldICmpIntrinsicWithConstant ; NFC 1. Rename variables to be consistent with related/preceding code (may want to reorganize). 2. Fix comments/formatting. llvm-svn: 281140
2016-09-10[InstCombine] rename and reorganize some icmp folding functions; NFCSanjay Patel2-24/+23
Everything under foldICmpInstWithConstant() should now be working for splat vectors via m_APInt matchers. Ie, I've removed all of the FIXMEs that I added while cleaning that section up. Note that not all of the associated FIXMEs in the regression tests are gone though, because some of the tests require earlier folds that are still scalar-only. llvm-svn: 281139
2016-09-10We also need to pass swifterror in R12 under swiftcc not only under cccArnold Schwaighofer1-0/+3
rdar://28190687 llvm-svn: 281138
2016-09-10[AMDGPU] Refactor MUBUF/MTBUF instructionsValery Pykhtin6-1168/+1306
Differential revision: https://reviews.llvm.org/D24295 llvm-svn: 281137
2016-09-10[WebAssembly] Fix typos in commentsHeejin Ahn1-11/+14
llvm-svn: 281131
2016-09-10[libFuzzer] print a failed-merge warning only in the merge modeKostya Serebryany1-0/+1
llvm-svn: 281130
2016-09-10AMDGPU: Implement is{LoadFrom|StoreTo}FrameIndexMatt Arsenault6-21/+90
llvm-svn: 281128
2016-09-10AMDGPU: Fix scheduling info for spill pseudosMatt Arsenault1-2/+3
These defaulted to Write32Bit. I don't think this actually matters since these don't exist during scheduling. llvm-svn: 281127
2016-09-10[asan] Add flag to allow lifetime analysis of problematic allocasVitaly Buka1-0/+6
Summary: Could be useful for comparison when we suspect that alloca was skipped because of this. Reviewers: eugenis Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D24437 llvm-svn: 281126
2016-09-10[CodeGen] Rename MachineInstr::isInvariantLoad to ↵Justin Lebar8-16/+16
isDereferenceableInvariantLoad. NFC Summary: I want to separate out the notions of invariance and dereferenceability at the MI level, so that they correspond to the equivalent concepts at the IR level. (Currently an MI load is MI-invariant iff it's IR-invariant and IR-dereferenceable.) First step is renaming this function. Reviewers: chandlerc Subscribers: MatzeB, jfb, llvm-commits Differential Revision: https://reviews.llvm.org/D23370 llvm-svn: 281125
2016-09-10[libFuzzer] don't print help for internal flags Kostya Serebryany2-0/+3
llvm-svn: 281124
2016-09-10[libFuzzer] print a visible message if merge fails due to a crash Kostya Serebryany3-0/+24
llvm-svn: 281122
2016-09-09AMDGPU: Fix immediate folding logic when shrinking instructionsMatt Arsenault3-16/+10
If the literal is being folded into src0, it doesn't matter if it's an SGPR because it's being replaced with the literal. Also fixes initially selecting 32-bit versions of some instructions which also confused commuting. llvm-svn: 281117
2016-09-09Inliner: Don't mark swifterror allocas with lifetime markersArnold Schwaighofer1-0/+3
This would create a bitcast use which fails the verifier: swifterror values may only be used by loads, stores, and as function arguments. rdar://28233244 llvm-svn: 281114
2016-09-09X86: Fold tail calls into conditional branches also for 64-bit (PR26302)Hans Wennborg4-12/+40
This extends the optimization in r280832 to also work for 64-bit. The only quirk is that we can't do this for 64-bit Windows (yet). Differential Revision: https://reviews.llvm.org/D24423 llvm-svn: 281113
2016-09-09AMDGPU: Run LoadStoreVectorizer pass by defaultMatt Arsenault2-1/+4
llvm-svn: 281112
2016-09-09[libFuzzer] use sizeof() in tests instead of 4 and 8Kostya Serebryany2-6/+6
llvm-svn: 281111
2016-09-09LSV: Fix incorrectly increasing alignmentMatt Arsenault1-18/+16
If the unaligned access has a dynamic offset, it may be odd which would make the adjusted alignment incorrect to use. llvm-svn: 281110
2016-09-09[InstCombine] use m_APInt to allow icmp ult X, C folds for splat constant ↵Sanjay Patel1-8/+13
vectors llvm-svn: 281107
2016-09-09[libFuzzer] one more puzzle for value profileKostya Serebryany3-0/+25
llvm-svn: 281106
2016-09-09[X86][XOP] Fix VPERMIL2PD mask creation on 32-bit targetsSimon Pilgrim1-5/+5
Use getConstVector helper to correctly create v2i64/v4i64 constants on 32-bit targets llvm-svn: 281105
2016-09-09[Hexagon] Fix disassembler crash after r279255Krzysztof Parzyszek1-0/+3
When p0 was added as an explicit operand to the duplex subinstructions, the disassembler was not updated to reflect this. llvm-svn: 281104
2016-09-09Create phi nodes for swifterror values at the end of the phi instructions listArnold Schwaighofer1-1/+1
ISel makes assumption about the order of phi nodes. rdar://28190150 llvm-svn: 281095
2016-09-09[NVPTX] Implement llvm.fabs.f32, llvm.max.f32, etc.Justin Lebar2-16/+132
Summary: Previously these only worked via NVPTX-specific intrinsics. This change will allow us to convert these target-specific intrinsics into the general LLVM versions, allowing existing LLVM passes to reason about their behavior. It also gets us some minor codegen improvements as-is, from situations where we canonicalize code into one of these llvm intrinsics. Reviewers: majnemer Subscribers: llvm-commits, jholewinski, tra Differential Revision: https://reviews.llvm.org/D24300 llvm-svn: 281092
2016-09-09ARM: move the builtins libcall CC setupSaleem Abdulrasool3-166/+171
Move the target specific setup into the target specific lowering setup. As pointed out by Anton, the initial change was moving this too high up the stack resulting in a violation of the layering (the target generic code path setup target specific bits). Sink this into the ARM specific setup. NFC. llvm-svn: 281088
2016-09-09Add a lower level zlib::uncompress.Rafael Espindola1-6/+13
SmallVectors are convenient, but they don't cover every use case. In particular, they are fairly large (3 pointers + one element) and there is no way to take ownership of the buffer to put it somewhere else. This patch then adds a lower lever interface that works with any buffer. llvm-svn: 281082
2016-09-09AMDGPU : Fix mqsad_u32_u8 instruction incorrect data type.Wei Ding3-9/+17
Differential Revision: http://reviews.llvm.org/D23700 llvm-svn: 281081
2016-09-09AMDGPU/SI: Make sure llvm.amdgcn.implicitarg.ptr() is 8-byte aligned for HSATom Stellard2-1/+6
Reviewers: arsenm Subscribers: arsenm, wdng, nhaehnle, llvm-commits Differential Revision: https://reviews.llvm.org/D24405 llvm-svn: 281080
2016-09-09[pdb] Print out some more info when dumping a raw stream.Zachary Turner1-0/+4
We have various command line options that print the type of a stream, the size of a stream, etc but nowhere that it can all be viewed together. Since a previous patch introduced the ability to dump the bytes of a stream, this seems like a good place to present a full view of the stream's properties including its size, what kind of data it represents, and the blocks it occupies. So I added the ability to print that information to the -stream-data command line option. llvm-svn: 281077
generated by cgit v1.1 at 2025-10-14 22:02:01 +0000