summaryrefslogtreecommitdiffstats
path: root/llvm/lib
Commit message (Collapse)AuthorAgeFilesLines
* [DAGCombine] Don't combine (and (setne X, 0), (setne X, -1)) --> (setuge ↵Simon Pilgrim2017-12-261-1/+2
| | | | | | | | (add X, 1), 2) for i1 Reduced from oss-fuzz #4773 test case llvm-svn: 321455
* [InstSimplify] Check for in range extraction index before calling ↵Simon Pilgrim2017-12-261-2/+3
| | | | | | | | APInt::getZExtValue() Reduced from oss-fuzz #4768 test case llvm-svn: 321454
* [X86] Pass itins.rr/itins.rm through properly for some instructions.Craig Topper2017-12-261-11/+12
| | | | llvm-svn: 321452
* [X86] Use SSE_INTMUL_ITINS_P for the AVX-512 MUL instructions to match their ↵Craig Topper2017-12-261-5/+5
| | | | | | SSE/AVX counterparts. llvm-svn: 321451
* [X86] Fix typo in assert message.Craig Topper2017-12-261-1/+1
| | | | llvm-svn: 321450
* [ThinLTO] Don't import functions with noinline attributeEugene Leviant2017-12-251-1/+3
| | | | | | Differential revision: https://reviews.llvm.org/D41489 llvm-svn: 321443
* [MC] - Disallow invalid section groups declarations.George Rimar2017-12-251-2/+2
| | | | | | | | | | | | This fixes parseGroup() so that it always sets error condition on error. Previously it was not done, because parseIdentifier looks never do that, assuming that caller should do it if he wants to. So previously cases from test were silently accepted and produced broken output. Differential revision: https://reviews.llvm.org/D41559 llvm-svn: 321439
* [SafepointIRVerifier] Allow non-dereferencing uses of unrelocated or ↵Max Kazantsev2017-12-251-19/+137
| | | | | | | | | | | | | | | | | | poisoned PHI nodes PHI that has at least one unrelocated input cannot cause any issues by itself, though its uses should be carefully verified. With this patch PHIs are allowed to have any inputs but when all inputs are unrelocated the PHI is marked as unrelocated and if not all inputs are unrelocated then the PHI is marked as poisoned. Poisoned pointers can be used only in three ways: to derive new pointers, in PHIs or in comparisons against constants that are exclusively derived from null. Patch by Daniil Suchkov! Differential Revision: https://reviews.llvm.org/D41006 llvm-svn: 321438
* [X86] Add a DAG combines to turn vXi64 muls into VPMULDQ/VPMULUDQ if the ↵Craig Topper2017-12-251-0/+34
| | | | | | | | | | upper bits are all sign bits or zeros. Normally we catch this during lowering, but vXi64 mul is considered legal when we have AVX512DQ. This DAG combine allows us to avoid PMULLQ with AVX512DQ if we can prove its unnecessary. PMULLQ is 3 uops that take 4 cycles each. While pmuldq/pmuludq is only one 4 cycle uop. llvm-svn: 321437
* [X86] Make some helper methods static functions instead. NFCCraig Topper2017-12-252-19/+15
| | | | llvm-svn: 321433
* [X86] Use SelectionDAG::getFPExtendOrRound to simplify some code.Craig Topper2017-12-251-10/+1
| | | | llvm-svn: 321432
* Make helpers static. No functionality change.Benjamin Kramer2017-12-243-5/+14
| | | | llvm-svn: 321425
* [X86][X87] Mark pseudo memory fold instructions as load/sideeffects ↵Simon Pilgrim2017-12-241-4/+2
| | | | | | | | (PR21160, PR34080, PR34454). Match regular x87 memory fold instructions with load/sideeffects tags, to prevent the schedulers from re-ordering them across the fnstcw/fldcw sequences for truncating stores while they are still pseudo during the stack conversion pass. llvm-svn: 321424
* [X86] Fix (v2f64 (s/uint_to_fp (v2i1))) to avoid scalarization without AVX512DQ.Craig Topper2017-12-241-7/+18
| | | | | | Previously we extended v2i1 to v2f64 and then tried to use cvtuqq2pd/cvtqq2pd, but that only works with avx512dq. So we ended up scalarizing it. Now we widen to v4i1 first and extend to v4i32. llvm-svn: 321420
* [MC] - Teach llvm-mc to handle comdats whose names are numbers.George Rimar2017-12-241-1/+5
| | | | | | | | | | | | | | | Currently llvm-mc ignores COMDATs whose names are numbers, for example following code: .section .foo,"G",@progbits,123,comdat would produce no COMDATs at all. Patch fixes the issue. Differential revision: https://reviews.llvm.org/D41552 llvm-svn: 321419
* [DAGCombiners] Don't turn ANDs to shuffles with zero so early. Give some ↵Craig Topper2017-12-241-7/+8
| | | | | | | | other combines a chance to run. This moves the combine for turning ANDs into shuffle with zero out of SimplifyVBinOps and places it only in visitAND below the reassociate handling. This fixes the specific case I noticed where we failed to combine two ands with constants. llvm-svn: 321417
* [X86] Add assembler predicates to BITALG/VBMI2/VNNI features to be ↵Craig Topper2017-12-241-3/+6
| | | | | | consistent with the other AVX512 ISAs. llvm-svn: 321416
* [X86] Teach WidenMaskArithmetic to handle any constant buildvector on the ↵Craig Topper2017-12-241-10/+5
| | | | | | RHS not just all zeros/ones. llvm-svn: 321415
* [SelectionDAG] Teach SelectionDAG::getNode to constant fold zext/aext/sext ↵Craig Topper2017-12-231-0/+3
| | | | | | of constant build vectors. llvm-svn: 321414
* [CallSiteSplitting] Remove isOrHeader restriction.Florian Hahn2017-12-231-27/+19
| | | | | | | | | | | By following the single predecessors of the predecessors of the call site, we do not need to restrict the control flow. Reviewed By: junbuml, davide Differential Revision: https://reviews.llvm.org/D40729 llvm-svn: 321413
* [X86] Remove type restrictions from WidenMaskArithmetic.Craig Topper2017-12-231-7/+6
| | | | | | This can help AVX-512 code where mask types are legal allowing us to remove extends and truncates to/from mask types. llvm-svn: 321408
* [X86] In WidenMaskArithmetic, make sure we check the input type of a ↵Craig Topper2017-12-231-1/+2
| | | | | | | | truncate on N1. Later in the code we explicitly bypass the truncate so we should be checking its type to make sure that it's safe. llvm-svn: 321407
* [X86] Remove unneeded EVT variable. NFCCraig Topper2017-12-231-6/+5
| | | | | | | | Immediately after it is created we check if its equal to another EVT. Then we inconsistently use one or the other variables in the code below. Instead do the equality check directly on the getValueType result and remove the variable. Use the origina VT variable throughout the remaining code. llvm-svn: 321406
* [X86][X87] Wrap FpI_ pseudo to use PseudoI. NFCI.Simon Pilgrim2017-12-231-2/+1
| | | | llvm-svn: 321405
* [SCCP] Manually fold branches on undef.Davide Italiano2017-12-231-3/+26
| | | | | | | | | | | | | | | This code was originally removed and replace with an assertion because believed unnecessary. It turns out there was simply no test coverage for this case, and the constant folder doesn't yet know about patterns like `br undef %label1, %label2`. Presumably at some point the constant folder might learn about these patterns, but it's a broader change. A testcase will be added to make sure this doesn't regress again in the future. Fixes PR35723. llvm-svn: 321402
* [X86] Add default InstrItinClass to PseudoISimon Pilgrim2017-12-231-2/+3
| | | | | | This will be used to help tidyup existing pseudos that we've added scheduling info to. llvm-svn: 321401
* [X86] Pass the right VT to the getZeroExtendInReg introduced in r321398Craig Topper2017-12-231-1/+1
| | | | | | Apparently we don't have tests for this which I didn't realize before. I'll try to fix that but wanted to fix the obvious bug. llvm-svn: 321399
* [X86] Use SelectionDAG::getZeroExtendInReg instead of implementing it manually.Craig Topper2017-12-231-9/+3
| | | | llvm-svn: 321398
* [SelectionDAG][X86] Don't use ->getValueType(0) after a call to getOperand ↵Craig Topper2017-12-234-14/+14
| | | | | | | | | | to get the type of the operand. getOperand returns an SDValue that contains the node and the result number. There is no guarantee that the result number if 0. By using the -> operator we are calling SDNode::getValueType rather than SDValue::getValueType. This requires supplying a result number and we shouldn't assume it was 0. I don't have a test case. Just noticed while cleaning up some other code and saw that it occurred in other places. llvm-svn: 321397
* [DAG] Add missing case check from findbaseoffset merge from r321389.Nirav Dave2017-12-221-2/+4
| | | | llvm-svn: 321391
* Integrate findBaseOffset address analyses to BaseIndexOffset. NFCI.Nirav Dave2017-12-222-70/+27
| | | | | | | | | BaseIndexOffset supercedes findBaseOffset analysis save only Constant Pool addresses. Migrate analysis to BaseIndexOffset. Relanding after correcting base address matching check. llvm-svn: 321389
* [WebAssembly] MC: Fix for address taken aliasesSam Clegg2017-12-221-39/+30
| | | | | | | | | | | | | | Previously, taking the address for an alias would result in: "Symbol not found in table index space" Increase test coverage for weak aliases. This code should be more efficient too as it avoids building the `IsAddressTaken` set. Differential Revision: https://reviews.llvm.org/D41510 llvm-svn: 321384
* [MemorySSA] Allow reordering of loads that alias in the presence of volatile ↵Alina Sbirlea2017-12-221-29/+10
| | | | | | | | | | | | | | | | | | | loads. Summary: Make MemorySSA allow reordering of two loads that may alias, when one is volatile. This makes MemorySSA less conservative and behaving the same as the AliasSetTracker. For more context, see D16875. LLVM language reference: "The optimizers must not change the number of volatile operations or change their order of execution relative to other volatile operations. The optimizers may change the order of volatile operations relative to non-volatile operations. This is not Java’s “volatile” and has no cross-thread synchronization behavior." Reviewers: george.burgess.iv, dberlin Subscribers: sanjoy, reames, hfinkel, llvm-commits, Prazek Differential Revision: https://reviews.llvm.org/D41525 llvm-svn: 321382
* Revert "[DAG] Integrate findBaseOffset address analyses to BaseIndexOffset. ↵Nirav Dave2017-12-222-27/+70
| | | | | | | | | | NFCI." which was causing miscompilations in for some test-suite components. This reverts commit 3e9de9ff0f3162920a2a3cba51c7dc14b54b4d16. llvm-svn: 321380
* [SimplifyCFG] Don't do if-conversion if there is a long dependence chainGuozhi Wei2017-12-222-0/+183
| | | | | | | | | | If after if-conversion, most of the instructions in this new BB construct a long and slow dependence chain, it may be slower than cmp/branch, even if the branch has a high miss rate, because the control dependence is transformed into data dependence, and control dependence can be speculated, and thus, the second part can execute in parallel with the first part on modern OOO processor. This patch checks for the long dependence chain, and give up if-conversion if find one. Differential Revision: https://reviews.llvm.org/D39352 llvm-svn: 321377
* [ThinLTO][CachePruning] explicitly disable pruningBen Dunbobbin2017-12-221-5/+5
| | | | | | | | | | | In https://reviews.llvm.org/rL321077 and https://reviews.llvm.org/D41231 I fixed a regression in the c-api which prevented the pruning from being *effectively* disabled. However this approach, helpfully recommended by @labath, is cleaner. It is also nice to remove the weasel words about effectively disabling from the api comments. Differential Revision: https://reviews.llvm.org/D41497 llvm-svn: 321376
* (Re-landing) Expose a TargetMachine::getTargetTransformInfo functionSanjoy Das2017-12-2229-85/+72
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Re-land r321234. It had to be reverted because it broke the shared library build. The shared library build broke because there was a missing LLVMBuild dependency from lib/Passes (which calls TargetMachine::getTargetIRAnalysis) to lib/Target. As far as I can tell, this problem was always there but was somehow masked before (perhaps because TargetMachine::getTargetIRAnalysis was a virtual function). Original commit message: This makes the TargetMachine interface a bit simpler. We still need the std::function in TargetIRAnalysis to avoid having to add a dependency from Analysis to Target. See discussion: http://lists.llvm.org/pipermail/llvm-dev/2017-December/119749.html I avoided adding all of the backend owners to this review since the change is simple, but let me know if you feel differently about this. Reviewers: echristo, MatzeB, hfinkel Reviewed By: hfinkel Subscribers: jholewinski, jfb, arsenm, dschuff, mcrosier, sdardis, nemanjai, nhaehnle, javed.absar, sbc100, jgravelle-google, aheejin, kbarton, llvm-commits Differential Revision: https://reviews.llvm.org/D41464 llvm-svn: 321375
* [AMDGPU][MC] Corrected handling of negative expressionsDmitry Preobrazhensky2017-12-221-1/+6
| | | | | | | | | | See bug 35716: https://bugs.llvm.org/show_bug.cgi?id=35716 Reviewers: artem.tamazov, arsenm Differential Revision: https://reviews.llvm.org/D41488 llvm-svn: 321372
* [SelectionDAG] Reverse the order of operands in the ISD::ADD created by ↵Craig Topper2017-12-221-1/+1
| | | | | | | | | | TargetLowering::getVectorElementPointer so that the FrameIndex is on the left. This seems to improve X86's ability to match this into an address computation. Otherwise the other operand gets assigned to the base register and the stack pointer + frame index ends up in the index register. But index registers can't encode ESP/RSP so we end up having to move it into another register to meet the constraint. I could try to improve the address matcher in X86, but swapping the producer seemed easier. Several other places already have the operands in this order so this is at least consistent. llvm-svn: 321370
* [X86] When lowering insert_vector_elt/extract_vector_elt of vXi1 with a ↵Craig Topper2017-12-221-8/+6
| | | | | | | | non-constant index just use either a 128-bit type or the vXi8 type with the correct number of elements. Despite what the comment said there isn't better codegen for 512-bit vectors. The 128/256/512 bit implementation jus stores to memory and loads an element. There's no advantage to doing that with a larger size. In fact in many cases it causes a stack realignment and generates worse code. llvm-svn: 321369
* [X86] Improve the printing of address mode during isel matching.Craig Topper2017-12-221-4/+5
| | | | | | Fix some inconsistent new line behavior and only print the FrameIndex when the address mode is a FrameIndexBase addressing mode. llvm-svn: 321368
* [AMDGPU][MC] Corrected parsing of optional operands for ds_swizzle_b32Dmitry Preobrazhensky2017-12-221-1/+3
| | | | | | | | | | See bug 35645: https://bugs.llvm.org/show_bug.cgi?id=35645 Reviewers: artem.tamazov, arsenm Differential Revision: https://reviews.llvm.org/D41186 llvm-svn: 321367
* [InlineCost] Find more free binary operationsHaicheng Wu2017-12-221-40/+18
| | | | | | | | | | | | Currently, inline cost model considers a binary operator as free only if both its operands are constants. Some simple cases are missing such as a + 0, a - a, etc. This patch modifies visitBinaryOperator() to call SimplifyBinOp() without going through simplifyInstruction() to get rid of the constant restriction. Thus, visitAnd() and visitOr() are not needed. Differential Revision: https://reviews.llvm.org/D41494 llvm-svn: 321366
* [DAG] Integrate findBaseOffset address analyses to BaseIndexOffset. NFCI.Nirav Dave2017-12-222-70/+27
| | | | | | | BaseIndexOffset supercedes findBaseOffset analysis save only Constant Pool addresses. Migrate analysis to BaseIndexOffset. llvm-svn: 321364
* [AMDGPU][MC] Added support of 256- and 512-bit tuples of ttmp registersDmitry Preobrazhensky2017-12-227-43/+197
| | | | | | | | | | | | See bug 35561: https://bugs.llvm.org/show_bug.cgi?id=35561 This patch also affects implementation of SGPR and VGPR registers though changes are cosmetic. Reviewers: artem.tamazov, arsenm Differential Revision: https://reviews.llvm.org/D41437 llvm-svn: 321359
* [ARM GlobalISel] Support G_INTTOPTR and G_PTRTOINT for s32Diana Picus2017-12-223-0/+30
| | | | | | | Mark conversions between pointers and 32-bit scalars as legal, map them to the GPR and select to a simple COPY. llvm-svn: 321356
* [ARM GlobalISel] Support pointer constantsDiana Picus2017-12-222-1/+11
| | | | | | | | | | Pointer constants are pretty rare, since we usually represent them as integer constants and then cast to pointer. One notable exception is the null pointer constant, which is represented directly as a G_CONSTANT 0 with pointer type. Mark it as legal and make sure it is selected like any other integer constant. llvm-svn: 321354
* [DAGCombine] Revert r321259Sam Parker2017-12-221-26/+0
| | | | | | | Improve ReduceLoadWidth for SRL Patch is causing an issue on the PPC64 BE santizer. llvm-svn: 321349
* Rewrite the cached map used for locating the most precise DIE amongChandler Carruth2017-12-221-26/+360
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | inlined subroutines for a given address. This is essentially the hot path of llvm-symbolizer when extracting inlined frames during symbolization. Previously, we would read every subprogram and every inlined subroutine, building a std::map across the entire PC space to the best DIE, and then do only a handful of queries as we symbolized a backtrace. A huge fraction of the time was spent building the map itself. This patch changes it two a two-level system. First, we just build a map from PC-interval to DWARF subprograms. These are required to be disjoint and so constructing this is pretty easy. Second, we build a map *just* for the inlined subroutines within the subprogram containing the query address. This allows us to look at far fewer DIEs and build a *much* smaller set of cached maps in the llvm-symbolizer case where only a few address get symbolized during the entire run. It also builds both interval maps in a very different way. It constructs a single flat vector of pairs that maps from offset -> index. The indices point into collections of DIE objects, but can also be "tombstones" (-1) to mark gaps. In the case of subprograms, this mostly just simplifies the data structure a bit. For inlined subroutines, because we carefully split them as we build the map, we end up in many cases having no holes and not having to store both start and stop offsets. Finally, the PC ranges for the inlined subroutines are compressed into 32-bits by making them relative to the base PC of the outer subprogram. This means that if you have a single function body with over 2gb of executable code in it, we will stop mapping address past the first 2gb of that function into inlined subroutines and just give you the subprogram. This doesn't seem like a problem. ;] All of this combines to make llvm-symbolizer *well* over 2x faster for symbolizing backtraces out of LLVM's unittests. Death-test heavy unit tests are running >2x faster. I'm still going to look at completely disabling symbolization there, but figured while I had a good benchmark we should make symbolization a bit better. Sadly, the logic to build the flat interval map for the inlined subroutines is fairly complex. I'm not super happy about this and welcome any simplifying suggestions. Huge thanks to Dave Blaikie who helped walk me through what the various things I needed to do in DWARF to make this work. Differential Revision: https://reviews.llvm.org/D40987 llvm-svn: 321345
* [X86] Add missing initialization for the HasPREFETCHWT1 subtarget variable.Craig Topper2017-12-221-0/+1
| | | | llvm-svn: 321340
OpenPOWER on IntegriCloud