summaryrefslogtreecommitdiffstats
path: root/llvm/lib
Commit message (Collapse)AuthorAgeFilesLines
* adding another optimization opportunity to readme fileEhsan Amiri2016-03-181-0/+11
| | | | llvm-svn: 263775
* [libFuzzer] read corpus dirs recursivelyKostya Serebryany2016-03-182-14/+25
| | | | llvm-svn: 263773
* [LoopDataPrefetch] Add TTI to limit the number of iterations to prefetch aheadAdam Nemet2016-03-184-0/+22
| | | | | | | | | | | | | | Summary: It can hurt performance to prefetch ahead too much. Be conservative for now and don't prefetch ahead more than 3 iterations on Cyclone. Reviewers: hfinkel Subscribers: llvm-commits, mzolotukhin Differential Revision: http://reviews.llvm.org/D17949 llvm-svn: 263772
* [LoopDataPrefetch/Aarch64] Allow selective prefetching of large-strided accessesAdam Nemet2016-03-184-0/+43
| | | | | | | | | | | | | | | | | | | | | Summary: And use this TTI for Cyclone. As it was explained in the original RFC (http://thread.gmane.org/gmane.comp.compilers.llvm.devel/92758), the HW prefetcher work up to 2KB strides. I am also adding tests for this and the previous change (D17943): * Cyclone prefetching accesses with a large stride * Cyclone not prefetching accesses with a small stride * Generic Aarch64 subtarget not prefetching either Reviewers: hfinkel Subscribers: aemerson, rengolin, llvm-commits, mzolotukhin Differential Revision: http://reviews.llvm.org/D17945 llvm-svn: 263771
* [Aarch64] Add pass LoopDataPrefetch for CycloneAdam Nemet2016-03-183-0/+34
| | | | | | | | | | | | | | | | | | | | Summary: This wires up the pass for Cyclone but keeps it off for now because we need a few more TTIs. The getPrefetchMinStride value is not very well tuned right now but it works well with CFP2006/433.milc which motivated this. Tests will be added as part of the upcoming large-stride prefetching patch. Reviewers: t.p.northover Subscribers: llvm-commits, aemerson, hfinkel, rengolin Differential Revision: http://reviews.llvm.org/D17943 llvm-svn: 263770
* [libFuzzer] improve -merge functionalityKostya Serebryany2016-03-186-73/+101
| | | | llvm-svn: 263769
* DebugInfo: Add ability to not emit DW_AT_vtable_elem_location for virtual ↵Peter Collingbourne2016-03-173-6/+10
| | | | | | | | | | | | functions. A virtual index of -1u indicates that the subprogram's virtual index is unrepresentable (for example, when using the relative vtable ABI), so do not emit a DW_AT_vtable_elem_location attribute for it. Differential Revision: http://reviews.llvm.org/D18236 llvm-svn: 263765
* [PPC, FastISel] Fix ordered/unordered fcmpTim Shen2016-03-171-7/+23
| | | | | | | | | | | | | | | | | | | | | For fcmp, major concern about the following 6 cases is NaN result. The comparison result consists of 4 bits, indicating lt, eq, gt and un (unordered), only one of which will be set. The result is generated by fcmpu instruction. However, bc instruction only inspects one of the first 3 bits, so when un is set, bc instruction may jump to to an undesired place. More specifically, if we expect an unordered comparison and un is set, we expect to always go to true branch; in such case UEQ, UGT and ULT still give false, which are undesired; but UNE, UGE, ULE happen to give true, since they are tested by inspecting !eq, !lt, !gt, respectively. Similarly, for ordered comparison, when un is set, we always expect the result to be false. In such case OGT, OLT and OEQ is good, since they are actually testing GT, LT, and EQ respectively, which are false. OGE, OLE and ONE are tested through !lt, !gt and !eq, and these are true. llvm-svn: 263753
* [LoopVectorize] Annotate versioned loop with noalias metadataAdam Nemet2016-03-172-23/+73
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: Use the new LoopVersioning facility (D16712) to add noalias metadata in the vector loop if we versioned with memchecks. This can enable some optimization opportunities further down the pipeline (see the included test or the benchmark improvement quoted in D16712). The test also covers the bug I had in the initial version in D16712. The vectorizer did not previously use LoopVersioning. The reason is that the vectorizer performs its transformations in single shot. It creates an empty single-block vector loop that it then populates with the widened, if-converted instructions. Thus creating an intermediate versioned scalar loop seems wasteful. So this patch (rather than bringing in LoopVersioning fully) adds a special interface to LoopVersioning to allow the vectorizer to add no-alias annotation while still performing its own versioning. As the vectorizer propagates metadata from the instructions in the original loop to the vector instructions we also check the pointer in the original instruction and see if LoopVersioning can add no-alias metadata based on the issued memchecks. Reviewers: hfinkel, nadav, mzolotukhin Subscribers: mzolotukhin, llvm-commits Differential Revision: http://reviews.llvm.org/D17191 llvm-svn: 263744
* [LoopVersioning] Annotate versioned loop with noalias metadataAdam Nemet2016-03-172-0/+90
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: If we decide to version a loop to benefit a transformation, it makes sense to record the now non-aliasing accesses in the newly versioned loop. This allows non-aliasing information to be used by subsequent passes. One example is 456.hmmer in SPECint2006 where after loop distribution, we vectorize one of the newly distributed loops. To vectorize we version this loop to fully disambiguate may-aliasing accesses. If we add the noalias markers, we can use the same information in a later DSE pass to eliminate some dead stores which amounts to ~25% of the instructions of this hot memory-pipeline-bound loop. The overall performance improves by 18% on our ARM64. The scoped noalias annotation is added in LoopVersioning. The patch then enables this for loop distribution. A follow-on patch will enable it for the vectorizer. Eventually this should be run by default when versioning the loop but first I'd like to get some feedback whether my understanding and application of scoped noalias metadata is correct. Essentially my approach was to have a separate alias domain for each versioning of the loop. For example, if we first version in loop distribution and then in vectorization of the distributed loops, we have a different set of memchecks for each versioning. By keeping the scopes in different domains they can conveniently be defined independently since different alias domains don't affect each other. As written, I also have a separate domain for each loop. This is not necessary and we could save some metadata here by using the same domain across the different loops. I don't think it's a big deal either way. Probably the best is to review the tests first to see if I mapped this problem correctly to scoped noalias markers. I have plenty of comments in the tests. Note that the interface is prepared for the vectorizer which needs the annotateInstWithNoAlias API. The vectorizer does not use LoopVersioning so we need a way to pass in the versioned instructions. This is also why the maps have to become part of the object state. Also currently, we only have an AA-aware DSE after the vectorizer if we also run the LTO pipeline. Depending how widely this triggers we may want to schedule a DSE toward the end of the regular pass pipeline. Reviewers: hfinkel, nadav, ashutosh.nema Subscribers: mssimpso, aemerson, llvm-commits, mcrosier Differential Revision: http://reviews.llvm.org/D16712 llvm-svn: 263743
* Bitcode: Error out instead of crashing on corrupt metadataJustin Bogner2016-03-171-20/+38
| | | | | | | | | | | | | | | | | I hit a crash in the bitcode reader on some corrupt input where an MDString had somehow been attached to an instruction instead of an MDNode. This input is pretty bogus, but we shouldn't be crashing on bad input here. This change adds error handling in all of the places where we currently have unchecked casts from Metadata to MDNode, which means we'll error out instead of crashing for that sort of input. Unfortunately, I don't have tests. Hitting this requires flipping bits in the input bitcode, and committing corrupt binary files to catch these cases is a bit too opaque and unmaintainable. llvm-svn: 263742
* ARM: stop asserting on weird <3 x Ty> vectors in ISelLowering.Tim Northover2016-03-171-2/+3
| | | | llvm-svn: 263741
* [libFuzzer] deprecate several flagsKostya Serebryany2016-03-177-51/+10
| | | | llvm-svn: 263739
* [libFuzzer] add __attribute__((no_sanitize_memory)) to two functions that ↵Kostya Serebryany2016-03-171-0/+2
| | | | | | may be called from signal handler(s) or from msan. This will hopefully avoid msan false reports which I can't reproduce llvm-svn: 263737
* [InstCombine] Combine A->B->A BitCastGuozhi Wei2016-03-172-0/+107
| | | | | | | | | | This patch enhances InstCombine to handle following case: A -> B bitcast PHI B -> A bitcast llvm-svn: 263734
* [Statepoints] Export a magic constant into a header; NFCSanjoy Das2016-03-171-1/+1
| | | | llvm-svn: 263733
* [PowerPC] Disable CTR loops optimization for soft float operationsPetar Jovanovic2016-03-171-0/+19
| | | | | | | | | | | | This patch prevents CTR loops optimization when using soft float operations inside loop body. Soft float operations use function calls, but function calls are not allowed inside CTR optimized loops. Patch by Aleksandar Beserminji. Differential Revision: http://reviews.llvm.org/D17600 llvm-svn: 263727
* [WebAssembly] Stackify code emitted by eliminateFrameIndex and SP writebackDerek Schuff2016-03-172-19/+85
| | | | | | | | | | | | | | | | | Summary: MRI::eliminateFrameIndex can emit several instructions to do address calculations; these can usually be stackified. Because instructions with FI operands can have subsequent operands which may be expression trees, find the top of the leftmost tree and insert the code before it, to keep the LIFO property. Also use stackified registers when writing back the SP value to memory in the epilog; it's unnecessary because SP will not be used after the epilog, and it results in better code. Differential Revision: http://reviews.llvm.org/D18234 llvm-svn: 263725
* [COFF] Refactor section alignment calculationDavid Majnemer2016-03-171-1/+1
| | | | | | | Section alignment isn't completely trivial, let it live in one place so that we may reuse it in LLVM. llvm-svn: 263722
* Forgot to commit this with r263692David Majnemer2016-03-171-1/+1
| | | | llvm-svn: 263721
* AMDGPU/SI: Do not generate s_waitcnt after ds_permute/ds_bpermuteChangpeng Fang2016-03-171-1/+1
| | | | | | | | | | | | | | | | Symmary: ds_permute/ds_bpermute do not read memory so s_waitcnt is not needed. Reviewers arsenm, tstellarAMD Subscribers llvm-commits, arsenm Differential Revision: http://reviews.llvm.org/D18197 llvm-svn: 263720
* AMDGPU: mark atomic instructions as sources of divergenceNicolai Haehnle2016-03-171-0/+7
| | | | | | | | | | | | | | Summary: As explained by the comment, threads will typically see different values returned by atomic instructions even if the arguments are equal. Reviewers: arsenm, tstellarAMD Subscribers: arsenm, llvm-commits Differential Revision: http://reviews.llvm.org/D18156 llvm-svn: 263719
* [X86][SSE] Simplified blend-with-zero combiningSimon Pilgrim2016-03-171-14/+13
| | | | | | | | We were being too aggressive in trying to combine a shuffle into a blend-with-zero pattern, often resulting in a endless loop of contrasting combines This patch stops the combine if we already have a blend in place (means we miss some domain corrections) llvm-svn: 263717
* propagate 'unpredictable' metadata on select instructions Sanjay Patel2016-03-171-4/+3
| | | | | | | | | | | | This is similar to D18133 where we allowed profile weights on select instructions. This extends that change to also allow the 'unpredictable' attribute of branches to apply to selects. A test to check that 'unpredictable' metadata is preserved when cloning instructions was checked in at: http://reviews.llvm.org/rL263648 Differential Revision: http://reviews.llvm.org/D18220 llvm-svn: 263716
* ARM: Revert SVN r253865, 254158, fix windows divisionSaleem Abdulrasool2016-03-171-7/+18
| | | | | | | | | | | | | | | | | | | | | | The two changes together weakened the test and caused a regression with division handling in MSVC mode. They were applied to avoid an assertion being triggered in the block frequency analysis. However, the underlying problem was simply being masked rather than solved properly. Address the actual underlying problem and revert the changes. Rather than analyze the cause of the assertion, the division failure was assumed to be an overflow. The underlying issue was a subtle bug in the BB construction in the emission of the div-by-zero check (WIN__DBZCHK). We did not construct the proper successor information in the basic blocks, nor did we update the PHIs associated with the basic block when we split them. This would result in assertions being triggered in the block frequency analysis pass. Although the original tests are being removed, the tests themselves performed very little in terms of validation but merely tested that we did not assert when generating code. Update this with new tests that actually ensure that we do not regress on the code generation. llvm-svn: 263714
* [mips] Use `formatImm` call to print immediate value in the `MipsInstPrinter`Simon Atanasyan2016-03-171-2/+2
| | | | | | | | | That allows, for example, to print hex-formatted immediates using llvm-objdump --print-imm-hex command line option. Differential Revision: http://reviews.llvm.org/D18195 llvm-svn: 263704
* [mips] Eliminate instances of "potentially uninitialised local variable" ↵Scott Egerton2016-03-171-16/+13
| | | | | | | | | | | | | | | | | | warnings, NFC Summary: This should eliminate all occurrences of this within LLVMMipsAsmParser. This patch is in response to http://reviews.llvm.org/D17983. I was unable to reproduce the warnings on my machine so please advise if this fixes the warnings. Reviewers: ariccio, vkalintiris, dsanders Subscribers: dblaikie, dsanders, llvm-commits Differential Revision: http://reviews.llvm.org/D18087 llvm-svn: 263703
* [Statepoints] Separate out logic for statepoint directives; NFCSanjoy Das2016-03-172-12/+33
| | | | | | | | | | | This splits out the logic that maps the `"statepoint-id"` attribute into the actual statepoint ID, and the `"statepoint-num-patch-bytes"` attribute into the number of patchable bytes the statpeoint is lowered into. The new home of this logic is in IR/Statepoint.cpp, and this refactoring will support similar functionality when lowering calls with deopt operand bundles in the future. llvm-svn: 263685
* [Statepoints] Minor NFC cleanupsSanjoy Das2016-03-171-34/+28
| | | | | | | Mostly code simplifcations, and bringing up IR/Statepoints.cpp up to LLVM coding style. llvm-svn: 263683
* [SelectionDAG] Remove visitStatepoint; NFCSanjoy Das2016-03-173-11/+2
| | | | | | | This way we have a single entry point into StatepointLowering. The method was a direct dispatch to LowerStatepoint anyway. llvm-svn: 263682
* Upgrade TBAA *before* upgrading intrinsicsChris Bieneman2016-03-161-3/+5
| | | | | | | | | | | | Summary: If TBAA is on an intrinsic and it gets upgraded and drops the TBAA we hit an odd assert. We should just upgrade the TBAA first because it doesn't have side-effects. Reviewers: reames, apilipenko, manmanren Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D18229 llvm-svn: 263673
* Fix indentation; NFCSanjoy Das2016-03-161-3/+2
| | | | llvm-svn: 263672
* Extract out a SelectionDAGBuilder::LowerAsStatepoint; NFCSanjoy Das2016-03-162-144/+197
| | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: This is a step towards implementing "direct" lowering of calls and invokes with deopt operand bundles into STATEPOINT nodes (as opposed to having them mandatorily pass through RewriteStatepointsForGC, which is the case today). This change extracts out a `SelectionDAGBuilder::LowerAsStatepoint` helper function that is able to lower a "statepoint like thing", and uses it to lower `gc.statepoint` calls. This is an NFC now, but in a later change we will use `LowerAsStatepoint` to directly lower calls and invokes with operand bundles without going through an intermediate `gc.statepoint` IR representation. FYI: I expect `SelectionDAGBuilder::StatepointInfo` will evolve as I add support for lowering non gc.statepoints, right now it is fairly tightly coupled with an IR level `gc.statepoint`. Reviewers: reames, pgavlin, JosephTremoulet Subscribers: sanjoy, mcrosier, llvm-commits Differential Revision: http://reviews.llvm.org/D18106 llvm-svn: 263671
* Variable name cleanup /NFCXinliang David Li2016-03-161-5/+6
| | | | llvm-svn: 263666
* Tweak some atomics functions in preparation for larger changes; NFC.James Y Knight2016-03-1615-31/+48
| | | | | | | | | | | | | | | | - Rename getATOMIC to getSYNC, as llvm will soon be able to emit both '__sync' libcalls and '__atomic' libcalls, and this function is for the '__sync' ones. - getInsertFencesForAtomic() has been replaced with shouldInsertFencesForAtomic(Instruction), so that the decision can be made per-instruction. This functionality will be used soon. - emitLeadingFence/emitTrailingFence are no longer called if shouldInsertFencesForAtomic returns false, and thus don't need to check the condition themselves. llvm-svn: 263665
* [SelectionDAG] Extract out populateCallLoweringInfo; NFCSanjoy Das2016-03-163-30/+31
| | | | | | | | | SelectionDAGBuilder::populateCallLoweringInfo is now used instead of SelectionDAGBuilder::lowerCallOperands. The populateCallLoweringInfo interface is more composable in face of design changes like http://reviews.llvm.org/D18106 llvm-svn: 263663
* [ProfileData] Make a utility method public, NFCVedant Kumar2016-03-161-2/+2
| | | | | | | | | | | The swift frontend needs to be able to look up PGO function name variables based on the original raw function name. That's because it's not possible to create PGO function name variables while emitting swift IR. Instead, we have to create the name variables while lowering swift IR to llvm IR, at which point we fix up all calls to the increment intrinsic to point to the right name variable. llvm-svn: 263662
* AMDGPU: Prevent uniform loops from becoming infiniteNicolai Haehnle2016-03-161-0/+6
| | | | | | | | | | | | | | Summary: Uniform loops where the branch leaving the loop is predicated on VCCNZ must be skipped if EXEC = 0, otherwise they will be infinite. Reviewers: tstellarAMD, arsenm Subscribers: arsenm, llvm-commits Differential Revision: http://reviews.llvm.org/D18137 llvm-svn: 263658
* [Hexagon] Adding missing break in switch statement. Extra operands would ↵Colin LeMahieu2016-03-161-0/+1
| | | | | | have been appended to the end. llvm-svn: 263657
* [SLP] Make DataLayout a member variable.Chad Rosier2016-03-161-38/+35
| | | | llvm-svn: 263656
* Revert "[LSR] Create fewer redundant instructions."Geoff Berry2016-03-161-22/+20
| | | | | | This reverts commit r263644. Investigating bootstrap failures. llvm-svn: 263655
* Removed trailing whitespaceSimon Pilgrim2016-03-161-12/+12
| | | | llvm-svn: 263650
* fix function names; NFCSanjay Patel2016-03-161-58/+60
| | | | llvm-svn: 263646
* [msan] Add a comment with a bug link.Evgeniy Stepanov2016-03-161-0/+3
| | | | llvm-svn: 263645
* [LSR] Create fewer redundant instructions.Geoff Berry2016-03-161-20/+22
| | | | | | | | | | | | | | | | | Summary: Fix LSRInstance::HoistInsertPosition() to check the original insert position block first for a canonical insertion point that is dominated by all inputs. This leads to SCEV being able to reuse more instructions since it currently tracks the instructions it creates for reuse by keeping a table of <Value, insert point> pairs. Reviewers: atrick Subscribers: mcrosier, mzolotukhin, llvm-commits Differential Revision: http://reviews.llvm.org/D18001 llvm-svn: 263644
* AMDGPU: Verify instructions in non-debug builds as wellMichel Danzer2016-03-161-3/+3
| | | | | | | | | | | | And emit an error if it fails. This prevents illegal instructions from getting sent to the GPU, which would potentially result in a hang. This is a candidate for the stable branch(es). Reviewed-by: Marek Olšák <marek.olsak@amd.com> llvm-svn: 263627
* AMDGPU/SI: Clean up indentation in SIInstrInfo::getDefaultRsrcDataFormatMichel Danzer2016-03-161-3/+3
| | | | | Reviewed-by: Tom Stellard <thomas.stellard@amd.com> llvm-svn: 263626
* AVX512BW: Fix SRA v64i8 lowering. Use PCMPGTM (cmp result in k register) for ↵Igor Breger2016-03-161-0/+5
| | | | | | | | 512bit vector because PCMPGT supported only for 128/256bit. Differential Revision: http://reviews.llvm.org/D18204 llvm-svn: 263624
* [JumpThreading] See through Cast InstructionsHaicheng Wu2016-03-161-0/+19
| | | | | | To capture more jump-thread opportunity. llvm-svn: 263618
* [Support] Add the 'Error' class for structured error handling.Lang Hames2016-03-161-0/+4
| | | | | | | | | | | | | | | | | This patch introduces the Error classs for lightweight, structured, recoverable error handling. It includes utilities for creating, manipulating and handling errors. The scheme is similar to exceptions, in that errors are described with user-defined types. Unlike exceptions however, errors are represented as ordinary return types in the API (similar to the way std::error_code is used). For usage notes see the LLVM programmer's manual, and the Error.h header. Usage examples can be found in unittests/Support/ErrorTest.cpp. Many thanks to David Blaikie, Mehdi Amini, Kevin Enderby and others on the llvm-dev and llvm-commits lists for lots of discussion and review. llvm-svn: 263609
OpenPOWER on IntegriCloud