summaryrefslogtreecommitdiffstats
path: root/llvm/lib
Commit message (Collapse)AuthorAgeFilesLines
...
* Allow binop C1, (select cc, CF, CT) -> select foldingStanislav Mekhanoshin2018-06-201-10/+28
| | | | | | | | | | Previously this folding was done only if select is a first operand. However, for non-commutative operations constant may go before select. Differential Revision: https://reviews.llvm.org/D48223 llvm-svn: 335167
* [mips] Correct predicates for loads, bit manipulation instructions and some ↵Simon Dardis2018-06-204-22/+33
| | | | | | | | | | | | pseudos Additionally, correct the definition of the rdhwr instruction. Reviewers: atanasyan, abeserminji, smaksimovic Differential Revision: https://reviews.llvm.org/D48216 llvm-svn: 335162
* AMDGPU: Fix scalar_to_vector for v4i16/v4f16Matt Arsenault2018-06-202-3/+12
| | | | llvm-svn: 335161
* AMDGPU: Fix missing C++ mode commentMatt Arsenault2018-06-201-1/+1
| | | | llvm-svn: 335160
* [IR] add/use isIntDivRem convenience functionSanjay Patel2018-06-202-6/+2
| | | | | | | | There are more existing potential users of this, but I've limited this patch to the first couple that I found to minimize typo risk. llvm-svn: 335157
* [PM/LoopUnswitch] Support partial trivial unswitching.Chandler Carruth2018-06-201-49/+171
| | | | | | | | | | | | | | | | | | | | | | | | | The idea of partial unswitching is to take a *part* of a branch's condition that is loop invariant and just unswitching that part. This primarily makes sense with i1 conditions of branches as opposed to switches. When dealing with i1 conditions, we can easily extract loop invariant inputs to a a branch and unswitch them to test them entirely outside the loop. As part of this, we now create much more significant cruft in the loop body, so this relies on adding cleanup passes to the loop pipeline and revisiting unswitched loops to do that cleanup before continuing to process them. This already appears to be more powerful at unswitching than the old loop unswitch pass, and so I'd appreciate pretty careful review in case I'm just missing some correctness checks. The `LIV-loop-condition` test case is not unswitched by the old unswitch pass, but is with this pass. Thanks to Sanjoy and Fedor for the review! Differential Revision: https://reviews.llvm.org/D46706 llvm-svn: 335156
* [RISCV] Accept fmv.s.x and fmv.x.s as mnemonic aliases for fmv.w.x and fmv.x.wAlex Bradbury2018-06-201-0/+5
| | | | | | | These instructions were renamed in version 2.2 of the user-level ISA spec, but the old name should also be accepted by standard tools. llvm-svn: 335154
* [Local] Generalize insertReplacementDbgValues, NFCVedant Kumar2018-06-201-5/+5
| | | | | | | | This utility should operate on Values, not Instructions. While I'm here, I've also made it possible to skip emitting replacement dbg.values for certain debug users (by having RewriteExpr return nullptr). llvm-svn: 335152
* [PredicateInfo] Order instructions in different BBs by DFSNumIn.Florian Hahn2018-06-202-8/+28
| | | | | | | | | | | | | | | | | | | | | | | | | Using OrderedInstructions::dominates as comparator for instructions in BBs without dominance relation can cause a non-deterministic order between such instructions. That in turn can cause us to materialize copies in a non-deterministic order. While this does not effect correctness, it causes some minor non-determinism in the final generated code, because values have slightly different labels. Without this patch, running -print-predicateinfo on a reasonably large module produces slightly different output on each run. This patch uses the dominator trees DFSInNum to order instruction from different BBs, which should enforce a deterministic ordering and guarantee that dominated instructions come after the instructions that dominate them. Reviewers: dberlin, efriedma, davide Reviewed By: efriedma Differential Revision: https://reviews.llvm.org/D48230 llvm-svn: 335150
* [DWARF] Don't keep a ref to possibly stack allocated data.Paul Robinson2018-06-201-2/+2
| | | | llvm-svn: 335146
* IRMover: Account for matching types present across modulesVlad Tsyrklevich2018-06-201-5/+14
| | | | | | | | | | | | | | | | | | | | | | | | Summary: Due to uniqueing of DICompositeTypes, it's possible for a type from one module to be loaded into another earlier module without being renamed. Then when the defining module is being IRMoved, the type can be used as a Mapping destination before being loaded, such that when it's requested using TypeMapTy::get() it will fail with an assertion that the type is a source type when it's actually a type in both the source and destination modules. Correctly handle that case by allowing a non-opaque non-literal struct type be present in both modules. Fix for PR37684. Reviewers: pcc, tejohnson Reviewed By: pcc, tejohnson Subscribers: tobiasvk, mehdi_amini, steven_wu, llvm-commits, kcc Differential Revision: https://reviews.llvm.org/D47898 llvm-svn: 335145
* [Local] Add a utility to insert replacement dbg.values, NFCVedant Kumar2018-06-202-11/+24
| | | | | | | | | | | | | | | | | | | | | The purpose of this utility is to make it easier for optimizations to insert replacement dbg.values for instructions they are deleting. This is useful in situations where salvageDebugInfo is inapplicable, say, because the new dbg.value cannot refer to an operand of the dying value. The utility is called insertReplacementDbgValues. It assumes that the instruction 'From' is going to be deleted, and inserts replacement dbg.values for each debug user of 'From'. The newly-inserted dbg.values refer to 'To' instead of 'From'. Each replacement dbg.value has the same location and variable as the debug user it replaces, has a DIExpression determined by the result of 'RewriteExpr' applied to an old debug user of 'From', and is placed before 'InsertBefore'. This should simplify future patches, like D48331. llvm-svn: 335144
* Remove a redundant initialization. NFCPaul Robinson2018-06-201-1/+1
| | | | llvm-svn: 335143
* [SLPVectorizer] Move isOneOf after InstructionsState type. NFCI.Simon Pilgrim2018-06-201-71/+71
| | | | | | A future patch will have isOneOf use InstructionsState. llvm-svn: 335142
* [DAG] Don't map a TableId to itself in the ReplacedValues mapBjorn Pettersson2018-06-202-3/+7
| | | | | | | | | | | | | | | | | Summary: Found some regressions (infinite loop in DAGTypeLegalizer::RemapId) after r334880. This patch makes sure that we do map a TableId to itself. Reviewers: niravd Reviewed By: niravd Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D48364 llvm-svn: 335141
* [DAG] Fix and-mask folding when narrowing loads.Nirav Dave2018-06-201-2/+3
| | | | | | | | | | | | | | | | Summary: Check that and masks are strictly smaller than implicit mask from narrowed load. Fixes PR37820. Reviewers: samparker, RKSimon, nemanjai Subscribers: hiraditya, llvm-commits Differential Revision: https://reviews.llvm.org/D48335 llvm-svn: 335137
* [WebAssembly] Update know failures for the wasm waterfallSam Clegg2018-06-201-7/+2
| | | | | | | | | | | | Summary: The waterfall no longer builds .s files and no longers uses the wasm-o when it builds object files. Subscribers: dschuff, jgravelle-google, aheejin, sunfish, llvm-commits Differential Revision: https://reviews.llvm.org/D48371 llvm-svn: 335135
* [SLPVectorizer] Use InstructionsState to record AltOpcodeSimon Pilgrim2018-06-201-72/+73
| | | | | | | | | | | | This is part of a move towards generalizing the alternate opcode mechanism and not just supporting (F)Add/(F)Sub counterparts. The patch embeds the AltOpcode in the InstructionsState instead of calling getAltOpcode so often. I'm hoping to eventually remove all uses of getAltOpcode and handle alternate opcode selection entirely within getSameOpcode, that will require us to use InstructionsState throughout the BoUpSLP call hierarchy (similar to some of the changes in D28907), which I will begin in future patches. Differential Revision: https://reviews.llvm.org/D48359 llvm-svn: 335134
* [SLPVectorizer] Relax "alternate" opcode vectorisation to work with any ↵Simon Pilgrim2018-06-201-11/+11
| | | | | | | | | | | | | | SK_Select shuffle pattern D47985 saw the old SK_Alternate 'alternating' shuffle mask replaced with the SK_Select mask which accepts either input operand for each lane, equivalent to a vector select with a constant condition operand. This patch updates SLPVectorizer to make full use of this SK_Select shuffle pattern by removing the 'isOdd()' limitation. The AArch64 regression will be fixed by D48172. Differential Revision: https://reviews.llvm.org/D48174 llvm-svn: 335130
* [InstSimplify] Fix missed optimization in simplifyUnsignedRangeCheck()Sanjay Patel2018-06-201-1/+1
| | | | | | | | | | | | | | | | | | | | | For both operands are unsigned, the following optimizations are valid, and missing: 1. X > Y && X != 0 --> X > Y 2. X > Y || X != 0 --> X != 0 3. X <= Y || X != 0 --> true 4. X <= Y || X == 0 --> X <= Y 5. X > Y && X == 0 --> false unsigned foo(unsigned x, unsigned y) { return x > y && x != 0; } should fold to x > y, but I found we haven't done it right now. besides, unsigned foo(unsigned x, unsigned y) { return x < y && y != 0; } Has been folded to x < y, so there may be a bug. Patch by: Li Jia He! Differential Revision: https://reviews.llvm.org/D47922 llvm-svn: 335129
* [RISCV] Add InstAlias definitions for fgt.{s|d}, fge.{s|d}Alex Bradbury2018-06-202-0/+14
| | | | | | | These are produced by GCC and supported by GAS, but not currently contained in the pseudoinstruction listing in the RISC-V ISA manual. llvm-svn: 335127
* [Hexagon] Remove 'T' from HasVNN predicates, NFCKrzysztof Parzyszek2018-06-2014-258/+258
| | | | | | Patch by Sumanth Gundapaneni. llvm-svn: 335124
* [mips] Fix the predicates of some DSP instructions from AdditionalPredicates ↵Simon Dardis2018-06-203-8/+8
| | | | | | | | | | to ASEPredicate Reviewers: atanasyan, abeserminji, smaksimovic Differential Revision: https://reviews.llvm.org/D48166 llvm-svn: 335122
* [InstCombine] ignore debuginfo when removing redundant assumes (PR37726)Sanjay Patel2018-06-201-3/+5
| | | | | | | | | | This is similar to: rL335083 Fixes:: https://bugs.llvm.org/show_bug.cgi?id=37726 llvm-svn: 335121
* [RISCV] Add InstAlias definitions for sgt and sgtuAlex Bradbury2018-06-201-0/+5
| | | | | | | These are produced by GCC and supported by GAS, but not currently contained in the pseudoinstruction listing in the RISC-V ISA manual. llvm-svn: 335120
* ARM: convert ORR instructions to ADD where possible on Thumb.Tim Northover2018-06-203-0/+39
| | | | | | | | | | | | Thumb has more 16-bit encoding space dedicated to ADD than ORR, allowing both a 3-address encoding and a wider range of immediates. So, particularly when optimizing for code size (but it doesn't make things worse elsewhere) it's beneficial to select an OR operation to an ADD if we know overflow won't occur. This is made even better by LLVM's penchant for putting operations in canonical form by converting the other way. llvm-svn: 335119
* [AArch64] Implement FLT_ROUNDS macro.Tim Northover2018-06-203-0/+28
| | | | | | | | | | Very similar to ARM implementation, just maps to an MRS. Should fix PR25191. Patch by Michael Brase. llvm-svn: 335118
* [llvm-mca][X86] Teach how to identify register writes that implicitly clear ↵Andrea Di Biagio2018-06-202-1/+83
| | | | | | | | | | | | | | | | | | | | | | | | | | | | the upper portion of a super-register. This patch teaches llvm-mca how to identify register writes that implicitly zero the upper portion of a super-register. On X86-64, a general purpose register is implemented in hardware as a 64-bit register. Quoting the Intel 64 Software Developer's Manual: "an update to the lower 32 bits of a 64 bit integer register is architecturally defined to zero extend the upper 32 bits". Also, a write to an XMM register performed by an AVX instruction implicitly zeroes the upper 128 bits of the aliasing YMM register. This patch adds a new method named clearsSuperRegisters to the MCInstrAnalysis interface to help identify instructions that implicitly clear the upper portion of a super-register. The rest of the patch teaches llvm-mca how to use that new method to obtain the information, and update the register dependencies accordingly. I compared the kernels from tests clear-super-register-1.s and clear-super-register-2.s against the output from perf on btver2. Previously there was a large discrepancy between the estimated IPC and the measured IPC. Now the differences are mostly in the noise. Differential Revision: https://reviews.llvm.org/D48225 llvm-svn: 335113
* [SLPVectorizer] Split Tree/Reduction cost calls to simplify debugging. NFCI.Simon Pilgrim2018-06-201-2/+3
| | | | llvm-svn: 335110
* [NFC][SCEV] Add tests related to bit masking (PR37793)Roman Lebedev2018-06-201-5/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: Related to https://bugs.llvm.org/show_bug.cgi?id=37793, https://reviews.llvm.org/D46760#1127287 We'd like to do this canonicalization https://rise4fun.com/Alive/Gmc But it is currently restricted by rL155136 / rL155362, which says: ``` // This is a constant shift of a constant shift. Be careful about hiding // shl instructions behind bit masks. They are used to represent multiplies // by a constant, and it is important that simple arithmetic expressions // are still recognizable by scalar evolution. // // The transforms applied to shl are very similar to the transforms applied // to mul by constant. We can be more aggressive about optimizing right // shifts. // // Combinations of right and left shifts will still be optimized in // DAGCombine where scalar evolution no longer applies. ``` I think these tests show that for *constants*, SCEV has no issues with that canonicalization. Reviewers: mkazantsev, spatel, efriedma, sanjoy Reviewed By: mkazantsev Subscribers: sanjoy, javed.absar, llvm-commits, stoklund, bixia Differential Revision: https://reviews.llvm.org/D48229 llvm-svn: 335101
* [X86][Znver1] Specify Register Files, RCU; FP scheduler capacity.Roman Lebedev2018-06-201-1/+26
| | | | | | | | | | | | | | | | | | | | | | | Summary: First off: i do not have any access to that processor, so this is purely theoretical, no benchmarks. I have been looking into b**d**ver2 scheduling profile, and while cross-referencing the existing b**t**ver2, znver1 profiles, and the reference docs (`Software Optimization Guide for AMD Family {15,16,17}h Processors`), i have noticed that only b**t**ver2 scheduling profile specifies these. Also, there is no mca test coverage. Reviewers: RKSimon, craig.topper, courbet, GGanesh, andreadb Reviewed By: GGanesh Subscribers: gbedwell, vprasad, ddibyend, shivaram, Ashutosh, javed.absar, llvm-commits Differential Revision: https://reviews.llvm.org/D47676 llvm-svn: 335099
* [X86] Add sched class WriteLAHFSAHF and fix values.Clement Courbet2018-06-2011-16/+17
| | | | | | | | | | | | | | | Summary: I ran llvm-exegesis on SKX, SKL, BDW, HSW, SNB. Atom is from Agner and SLM is a guess. I've left AMD processors alone. Reviewers: RKSimon, craig.topper Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D48079 llvm-svn: 335097
* [NFC] fix trivial typos in commentsHiroshi Inoue2018-06-206-43/+43
| | | | llvm-svn: 335096
* [DAGCombiner] Add some comments to some true/false arguments to make it ↵Craig Topper2018-06-201-2/+2
| | | | | | obvious what they are. NFC llvm-svn: 335095
* [SelectionDAG] Don't crash on inline assembly errors when the inline ↵Craig Topper2018-06-201-2/+11
| | | | | | | | | | | | | | | | | | | | | | | | | assembly return type is a struct. Summary: If we get an error building the SelectionDAG for inline assembly we try to continue and still build the DAG. But if the return type for the inline assembly is a struct we end up crashing because we try to create an UNDEF node with a struct type which isn't valid. Instead we need to create an UNDEF for each element of the struct and join them with merge_values. This patch relies on single operand merge_values being handled gracefully by getMergeValues. If the return type is void there will be no VTs returned by ComputeValueVTs and now we just return instead of calling setValue. Hopefully that's ok, I assumed nothing would need to look up the mapped value for void node. Fixes PR37359 Reviewers: rengolin, rovka, echristo, efriedma, bogner Reviewed By: efriedma Subscribers: craig.topper, llvm-commits Differential Revision: https://reviews.llvm.org/D46560 llvm-svn: 335093
* [X86] Use binary search of the EVEX->VEX static tables instead of populating ↵Craig Topper2018-06-201-38/+29
| | | | | | | | | | | | | | | | | | | | | two DenseMaps for lookups Summary: After r335018, the static tables are guaranteed sorted by the EVEX opcode to convert. We can use this to do a binary search and remove the need for any secondary data structures. Right now one table is 736 entries and the other is 482 entries. It might make sense to merge the two tables as a follow up. The effort it takes to select the table is probably similar to the extra binary search step it would require for a larger table. I haven't done any measurements to see if this has any effect on compile time, but I don't imagine that EVEX->VEX conversion is a place we spend a lot of time. Reviewers: RKSimon, spatel, chandlerc Reviewed By: RKSimon Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D48312 llvm-svn: 335092
* Revert r334980 and 334983Vlad Tsyrklevich2018-06-206-154/+18
| | | | | | | This reverts commits r334980 and r334983 because they were causing build timeouts on the x86_64-linux-ubsan bot. llvm-svn: 335085
* [IR] Introduce helpers to skip debug instructions (NFC)Vedant Kumar2018-06-193-11/+17
| | | | | | | | | | | | | | | | | | | | | | | This patch introduces two helpers to make it easier to ignore debug intrinsics: - Instruction::getNextNonDebugInstruction() This is just like Instruction::getNextNode(), except that it skips debug info. - skipDebugInfo(BasicBlock::iterator) A free function which advances a BasicBlock iterator past any debug info. This is a no-op when the iterator already points to a non-debug instruction. Part of: llvm.org/PR37728 Related to: https://reviews.llvm.org/D47874 Differential Revision: https://reviews.llvm.org/D48305 llvm-svn: 335083
* [InlineSpiller] Fix a crash due to lack of forward progress from remat ↵Philip Reames2018-06-191-0/+26
| | | | | | | | | | | | | | specifically for STATEPOINT This patch covers up a fairly fundemental issue around remat and register allocation which shows up with psuedo instructions with more vreg uses than there are physical registers. This patch essentially just disables remat for STATEPOINTs which are the only case we've seen so far, but long term we need a better fix. For STATEPOINTs specifically, this is a strict improvement. It unblocks progress towards enabling a currently off-by-default mode which integrates deopt bundle operand lowering with register allocator spilling so that we end up with smaller stack sizes and more optimally placed spills. Assming no other issues turn up during my next round of integration testing - which based on experience so far, is admittedly unlikely - we might finally be able to enable something I've been working towards in small bits and pieces for years now. :) For psuedo ops in general, there are a couple of ideas for a "proper fix" discussed on the bug, but I'm far enough outside my knowledge area to not be able to see any of them through to a successful conclusion. If anyone wants to help out here, please do. Differential Revision: https://reviews.llvm.org/D41098 llvm-svn: 335077
* [MachineOutliner] NFC: Remove insertOutlinerPrologue, rename ↵Jessica Paquette2018-06-195-23/+6
| | | | | | | | | | | | insertOutlinerEpilogue insertOutlinerPrologue was not used by any target, and prologue-esque code was beginning to appear in insertOutlinerEpilogue. Refactor that into one function, buildOutlinedFrame. This just removes insertOutlinerPrologue and renames insertOutlinerEpilogue. llvm-svn: 335076
* [WebAssembly] Fix liveness tracking info after drop insertionHeejin Ahn2018-06-191-2/+8
| | | | | | | | | | | | | | | | | | | | Summary: This fixes liveness tracking information after `drop` instruction insertion in ExplicitLocals pass. When a drop instruction is inserted to drop a dead register operand, the original operand should be marked not dead anymore because it is now used by the new drop instruction. And the operand to the new drop instruction should be marked killed instead. This bug caused some programs to fail when `llc` is run with `-verify-machineinstrs` option. Reviewers: dschuff Subscribers: sbc100, jgravelle-google, sunfish, llvm-commits Differential Revision: https://reviews.llvm.org/D48253 llvm-svn: 335074
* [IR] move shuffle mask queries from TTI to ShuffleVectorInstSanjay Patel2018-06-192-170/+122
| | | | | | | | | | | | | | | | The optimizer is getting smarter (eg, D47986) about differentiating shuffles based on its mask values, so we should make queries on the mask constant operand generally available to avoid code duplication. We'll probably use this soon in the vectorizers and instcombine (D48023 and https://bugs.llvm.org/show_bug.cgi?id=37806). We might clean up TTI a bit more once all of its current 'SK_*' options are covered. Differential Revision: https://reviews.llvm.org/D48236 llvm-svn: 335067
* [MIRParser] Update a diagnostic message to use the correct register sigil. NFCMatt Davis2018-06-191-1/+1
| | | | | | | | | | | | | | | | | | Summary: Patch r323922 changed the sigil for physical registers to '$', instead of '%'. An error message was missed during this change, and reports the wrong sigil. This patch corrects that diagnostic and the tests that check that error string. Reviewers: zer0, bjope Reviewed By: bjope Subscribers: bjope, thegameg, plotfi, llvm-commits Differential Revision: https://reviews.llvm.org/D48086 llvm-svn: 335066
* [Hexagon] Fix the value of HexagonII::TypeCVI_FIRSTKrzysztof Parzyszek2018-06-191-1/+1
| | | | | | | | | This value is the first vector instruction type in numerical order. The previous value was incorrect, leaving TypeCVI_GATHER outside of the range for vector instructions. This caused vector .new instructions to be incorrectly encoded in the presence of gather. llvm-svn: 335065
* [X86] Initialize FMA3Info directly in its constructor instead of relying on ↵Craig Topper2018-06-192-27/+2
| | | | | | | | | | | | std::call_once FMA3Info only exists as a managed static. As far as I know the ManagedStatic construction proccess is thread safe. It doesn't look like we ever access the ManagedStatic object without immediately doing a query on it that would require the map to be populated. So I don't think we're ever deferring the calculation of the tables from the construction of the object. So I think we should be able to just populate the FMA3Info map directly in the constructor and get rid of all of the initGroupsOnce stuff. Differential Revision: https://reviews.llvm.org/D48194 llvm-svn: 335064
* [X86] Don't fold unaligned loads into SSE ROUNDPS/ROUNDPD for ↵Craig Topper2018-06-191-10/+10
| | | | | | | | ceil/floor/nearbyint/rint/trunc. Incorrect patterns were added in r334460. This changes them to check alignment properly for SSE. llvm-svn: 335062
* [Hexagon] Enforce restrictions on packetizing cache instructionsKrzysztof Parzyszek2018-06-191-0/+4
| | | | llvm-svn: 335061
* [mips] Mark microMIPS64 as being unsupported.Simon Dardis2018-06-192-0/+5
| | | | | | | | | | There are no provided instruction definitions for this architecture. Reviewers: smaksimovic, atanasyan, abeserminji Differential Revision: https://reviews.llvm.org/D48320 llvm-svn: 335057
* [mips] Fix the predicates of some aliasesSimon Dardis2018-06-192-3/+6
| | | | | | | | | | | Previously, some aliases were marked as not being available for microMIPS32R6, but this was overridden at the top level. Reviewers: atanasyan, abeserminji, smaksimovic Differential Revision: https://reviews.llvm.org/D48321 llvm-svn: 335053
* [SLPVectorizer] Remove default OperandValueKind arguments from ↵Simon Pilgrim2018-06-191-14/+7
| | | | | | | | | | | | getArithmeticInstrCost calls (NFC) The getArithmeticInstrCost calls for shuffle vectors entry costs specify TargetTransformInfo::OperandValueKind arguments, but are just using the method's default values. This seems to be a copy + paste issue and doesn't affect the costs in anyway. The TargetTransformInfo::OperandValueProperties default arguments are already not being used. Noticed while working on D47985. Differential Revision: https://reviews.llvm.org/D48008 llvm-svn: 335045
OpenPOWER on IntegriCloud