summaryrefslogtreecommitdiffstats
path: root/llvm/lib/Target
Commit message (Collapse)AuthorAgeFilesLines
* AMDGPU: Remove old-style image intrinsicsNicolai Haehnle2018-06-216-995/+1
| | | | | | | | | | | | | | | | | | | | Summary: This also removes the need for atomic pseudo instructions, since we select the correct encoding directly in SITargetLowering::lowerImage for dimension-aware image intrinsics. Mesa uses dimension-aware image intrinsics since commit a9a7993441. Change-Id: I7473d20009476a4ed6d919cae4e6dca9ff42e77a Reviewers: arsenm, rampitec, mareko, tpr, b-sumner Subscribers: kzhuravl, wdng, yaxunl, dstuttard, t-tye, llvm-commits Differential Revision: https://reviews.llvm.org/D48167 llvm-svn: 335231
* AMDGPU: Select MIMG instructions manually in SITargetLoweringNicolai Haehnle2018-06-218-230/+345
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: Having TableGen patterns for image intrinsics is hitting limitations: for D16 we already have to manually pre-lower the packing of data values, and we will have to do the same for A16 eventually. Since there is already some custom C++ code anyway, it is arguably easier to just do everything in C++, now that we can use the beefed-up generic tables backend of TableGen to provide all the required metadata and map intrinsics to corresponding opcodes. With this approach, all image intrinsic lowering happens in SITargetLowering::lowerImage. That code is dense due to all the cases that it handles, but it should still be easier to follow than what we had before, by virtue of it all being done in a single location, and by virtue of not relying on the TableGen pattern magic that very few people really understand. This means that we will have MachineSDNodes with MIMG instructions during DAG combining, but that seems alright: previously we had intrinsic nodes instead, but those are similarly opaque to the generic CodeGen infrastructure, and the final pattern matching just did a 1:1 translation to machine instructions anyway. If anything, the fact that we now merge the address words into a vector before DAG combine should be an advantage. Change-Id: I417f26bd88f54ce9781c1668acc01f3f99774de6 Reviewers: arsenm, rampitec, rtaylor, tstellar Subscribers: kzhuravl, wdng, yaxunl, dstuttard, tpr, t-tye, llvm-commits Differential Revision: https://reviews.llvm.org/D48017 llvm-svn: 335228
* AMDGPU: Refactor MIMG instruction TableGen using generic tablesNicolai Haehnle2018-06-2110-442/+298
| | | | | | | | | | | | | | | | | | | | Summary: This allows us to access rich information about MIMG opcodes from C++ code. Simplifying the mapping between equivalent opcodes of different data size becomes quite natural. This also flattens the MIMG-related class and multiclass hierarchy a little, and collapses together some of the scaffolding for sample and gather4 opcodes. Change-Id: I1a2549fdc1e881ff100e5393d2d87e73729a0ccd Reviewers: arsenm, rampitec Subscribers: kzhuravl, wdng, yaxunl, dstuttard, tpr, t-tye, llvm-commits Differential Revision: https://reviews.llvm.org/D48016 llvm-svn: 335227
* AMDGPU: Use generic tables instead of SearchableTableNicolai Haehnle2018-06-215-22/+37
| | | | | | | | | | | | | Summary: Reviewers: arsenm, rampitec Subscribers: kzhuravl, wdng, yaxunl, dstuttard, tpr, t-tye, llvm-commits Differential Revision: https://reviews.llvm.org/D48014 Change-Id: Ibb43f90d955275571aff17d0c3ecfb5e5b299641 llvm-svn: 335226
* AMDGPU: Pass AMDGPUSampleVariant to MIMG_{Sampler,Gather}(_WQM)Nicolai Haehnle2018-06-211-69/+73
| | | | | | | | | | | | | | | | Summary: This will allows us to provide rich metadata about the instructions in tables that are accessible by custom C++ code. Change-Id: Id9305a26304ab6a6cceb6c65c8cd49141cc0101d Reviewers: arsenm, rampitec Subscribers: kzhuravl, wdng, yaxunl, dstuttard, tpr, t-tye, llvm-commits Differential Revision: https://reviews.llvm.org/D48011 llvm-svn: 335224
* AMDGPU: Add implicit def of SCC to kill and indirect pseudosNicolai Haehnle2018-06-211-2/+10
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: Kill instructions sometimes do use SCC in unusual circumstances, when v_cmpx cannot be used due to the operands that are involved. Additionally, even if SCC was never defined by the expansion, kill pseudos could previously occur between an s_cmp and an s_cbranch_scc, which breaks the SCC liveness tracking when the pseudo is expanded to split the basic block. While it would be possible to explicitly mark the SCC as live-in for the successor basic block, it's simpler to just mark the pseudo as using SCC, so that such a sequence is never emitted by instruction selection in the first place. A similar issue affects indirect source/dest pseudos in principle, although I haven't been able to come up with a test case where it actually matters (this affects instruction selection, so a MIR test can't be used). Fixes: dEQP-GLES3.functional.shaders.discard.dynamic_loop_always Change-Id: Ica8d82ecff1a763b892a1112cf1b06c948863a4f Reviewers: arsenm, rampitec Subscribers: kzhuravl, wdng, yaxunl, dstuttard, tpr, t-tye, llvm-commits Differential Revision: https://reviews.llvm.org/D47761 llvm-svn: 335223
* AMDGPU: Turn D16 for MIMG instructions into a regular operandNicolai Haehnle2018-06-2113-396/+297
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: This allows us to reduce the number of different machine instruction opcodes, which reduces the table sizes and helps flatten the TableGen multiclass hierarchies. We can do this because for each hardware MIMG opcode, we have a full set of IMAGE_xxx_Vn_Vm machine instructions for all required sizes of vdata and vaddr registers. Instead of having separate D16 machine instructions, a packed D16 instructions loading e.g. 4 components can simply use the same V2 opcode variant that non-D16 instructions use. We still require a TSFlag for D16 buffer instructions, because the D16-ness of buffer instructions is part of the opcode. Renaming the flag should help avoid future confusion. The one non-obvious code change is that for gather4 instructions, the disassembler can no longer automatically decide whether to use a V2 or a V4 variant. The existing logic which choose the correct variant for other MIMG instruction is extended to cover gather4 as well. As a bonus, some of the assembler error messages are now more helpful (e.g., complaining about a wrong data size instead of a non-existing instruction). While we're at it, delete a whole bunch of dead legacy TableGen code. Change-Id: I89b02c2841c06f95e662541433e597f5d4553978 Reviewers: arsenm, rampitec, kzhuravl, artem.tamazov, dp, rtaylor Subscribers: wdng, yaxunl, dstuttard, tpr, t-tye, llvm-commits Differential Revision: https://reviews.llvm.org/D47434 llvm-svn: 335222
* [X86][AVX] Reduce v4f64/v4i64 shuffle costs (PR37882)Simon Pilgrim2018-06-211-4/+4
| | | | | | These were being over cautious for costs for one/two op general shuffles - VSHUFPD doesn't have to replicate the same shuffle in both lanes like VSHUFPS does. llvm-svn: 335216
* [X86] Remove masking from 512-bit floating max/min intrinsics. Use select ↵Craig Topper2018-06-211-8/+4
| | | | | | instruction instead. llvm-svn: 335199
* [mips] Add microMIPS specific addressing patterns.Simon Dardis2018-06-202-91/+113
| | | | | | | | | | | | | These are identical but use microMIPS instructions instead of MIPS instructions. Also, flatten the 'let AdditionalPredicates = [InMicroMips]' by using the ISA_MICROMIPS adjective. Add tests for constant materialization. Reviewers: atanasyan, abeserminji, smaksimovic Differential Revision: https://reviews.llvm.org/D48275 llvm-svn: 335185
* [X86] Use setcc ISD opcode for AVX512 integer comparisons all the way to iselCraig Topper2018-06-207-166/+264
| | | | | | | | | | I don't believe there is any real reason to have separate X86 specific opcodes for vector compares. Setcc has the same behavior just uses a different encoding for the condition code. I had to change the CondCodeAction for SETLT and SETLE to prevent some transforms from changing SETGT lowering. Differential Revision: https://reviews.llvm.org/D43608 llvm-svn: 335173
* [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
* [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
* [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
* [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
* [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-201-1/+74
| | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* [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
* [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
* [MachineOutliner] NFC: Remove insertOutlinerPrologue, rename ↵Jessica Paquette2018-06-194-18/+4
| | | | | | | | | | | | 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
* [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
* [PowerPC] Fix label address calculation for ppc32Strahinja Petrovic2018-06-191-3/+4
| | | | | | | | This patch fixes calculating address of label on ppc32 (for -fPIC). Differential Revision: https://reviews.llvm.org/D46582 llvm-svn: 335043
* [X86] VRNDSCALE* folding from masked and scalar ffloor and fceil patternsMikhail Dvoretckii2018-06-193-5/+118
| | | | | | | | | | | This patch handles back-end folding of generic patterns created by lowering the X86 rounding intrinsics to native IR in cases where the instruction isn't a straightforward packed values rounding operation, but a masked operation or a scalar operation. Differential Revision: https://reviews.llvm.org/D45203 llvm-svn: 335037
* Test commit.Mikhail Dvoretckii2018-06-191-1/+1
| | | | llvm-svn: 335026
* If the arch is P9, we will select the DFLOADf32/DFLOADf64 pseudo instruction ↵QingShan Zhang2018-06-192-11/+23
| | | | | | | | | | | when we are loading a floating, and expand it post RA basing on the register pressure. However, we miss to do the add-imm peephole for these pseudo instruction. Differential Revision: https://reviews.llvm.org/D47568 Reviewed By: Nemanjai llvm-svn: 335024
* [X86] Add the ability to force an EVEX2VEX mapping table entry from the .td ↵Craig Topper2018-06-192-65/+128
| | | | | | | | | | | | | | files. Remove remaining manual table entries from the tablegen emitter. This adds an EVEX2VEXOverride string to the X86 instruction class in X86InstrFormats.td. If this field is set it will add manual entry in the EVEX->VEX tables that doesn't check the encoding information. Then use this mechanism to map VMOVDU/A8/16, 128-bit VALIGN, and VPSHUFF/I instructions to VEX instructions. Finally, remove the manual table from the emitter. This has the bonus of fully sorting the autogenerated EVEX->VEX tables by their EVEX instruction enum value. We may be able to use this to do a binary search for the conversion and get rid of the need to create a DenseMap. llvm-svn: 335018
* [X86] Add a new VEX_WPrefix encoding to tag EVEX instruction that have ↵Craig Topper2018-06-192-7/+12
| | | | | | | | | | | | | | VEX.W==1, but can be converted to their VEX equivalent that uses VEX.W==0. EVEX makes heavy use of the VEX.W bit to indicate 64-bit element vs 32-bit elements. Many of the VEX instructions were split into 2 versions with different masking granularity. The EVEX->VEX table generate can collapse the two versions if the VEX version uses is tagged as VEX_WIG. But if the VEX version is instead marked VEX.W==0 we can't combine them because we don't know if there is also a VEX version with VEX.W==1. This patch adds a new VEX_W1X tag that indicates the EVEX instruction encodes with VEX.W==1, but is safe to convert to a VEX instruction with VEX.W==0. This allows us to remove a bunch of manual EVEX->VEX table entries. We may want to look into splitting up the VEX_WPrefix field which would simplify the disassembler. llvm-svn: 335017
* [X86] Simplify the TSFlags checking code in EvexToVexInstPass. NFCICraig Topper2018-06-191-16/+6
| | | | | | The code was previously checking the L2 and L flag on 3 separate lines, treating the combination as an encoding. Instead its better to think of the L2 bit as being something that can't be done with VEX and early returning. Then we just need to check the L bit. llvm-svn: 335015
* [WebAssembly] Add more utility functionsHeejin Ahn2018-06-194-17/+192
| | | | | | | | | | | | | | | | Summary: Added more utility functions that will be used in EH-related passes Also changed `LoopBottom` function to `getBottom` and uses templates to be able to handle other classes as well, which will be used in CFGSort later. Reviewers: dschuff Subscribers: sbc100, jgravelle-google, sunfish, llvm-commits Differential Revision: https://reviews.llvm.org/D48262 llvm-svn: 335006
* [WebAssembly] Make rethrow instruction take a target BB argumentHeejin Ahn2018-06-181-2/+5
| | | | | | | | | | | | | | | | | | | | | Summary: This patch changes the rethrow instruction to take a BB argument in LLVM backend, like `br` and `br_if`s. This BB is a target catch BB the rethrow instruction unwinds to. This BB argument will be converted to an relative depth immediate at the end of CFGStackify pass, as in the same way of branches. RETHROW_TO_CALLER is a codegen-only instruction that should be used when a rethrow instruction does not have an unwind destination BB, i.e., it should rethrow to its caller function. Reviewers: dschuff Subscribers: sbc100, jgravelle-google, sunfish, llvm-commits Differential Revision: https://reviews.llvm.org/D48260 llvm-svn: 334998
* [X86] Remove ReadAfterLd from avx512_shift_rmbi multiclass.Craig Topper2018-06-181-1/+1
| | | | | | The instructions that use this class don't have another source register. So I think this was just marking one of the address operands as ReadAfterLd? llvm-svn: 334994
* Tidy comment language and explanation.Eric Christopher2018-06-181-5/+5
| | | | llvm-svn: 334990
* Pull non-lazy stub table emission into a separate function alongsideEric Christopher2018-06-181-41/+47
| | | | | | | the individual stub creation to increase readability a bit in the non-object file format specific function. llvm-svn: 334989
* Add return statements to make it clear that all of these are mutually ↵Eric Christopher2018-06-181-0/+4
| | | | | | | | exclusive conditions. else if would have worked just as well, but this keeps the original readability a bit more clear. llvm-svn: 334988
* [WebAssembly] Modified tablegen defs to have 2 parallel instuction sets.Wouter van Oortmerssen2018-06-1811-419/+634
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: One for register based, much like the existing definitions, and one for stack based (suffix _S). This allows us to use registers in most of LLVM (which works better), and stack based in MC (which results in a simpler and more readable assembler / disassembler). Tried to keep this change as small as possible while passing tests, follow-up commit will: - Add reg->stack conversion in MI. - Fix asm/disasm in MC to be stack based. - Fix emitter to be stack based. tests passing: llvm-lit -v `find test -name WebAssembly` test/CodeGen/WebAssembly test/MC/WebAssembly test/MC/Disassembler/WebAssembly test/DebugInfo/WebAssembly test/CodeGen/MIR/WebAssembly test/tools/llvm-objdump/WebAssembly Reviewers: dschuff, sbc100, jgravelle-google, sunfish Subscribers: aheejin, JDevlieghere, llvm-commits Differential Revision: https://reviews.llvm.org/D48183 llvm-svn: 334985
* [AArch64][SVE] Asm: Fix predicate pattern diagnostics.Sander de Smalen2018-06-181-4/+6
| | | | | | | | | | | | | | | This patch uses the DiagnosticPredicate for SVE predicate patterns to improve their diagnostics, now giving a 'invalid operand' diagnostic if the type is not an immediate or one of the expected pattern labels. Reviewers: samparker, SjoerdMeijer, javed.absar, fhahn Reviewed By: fhahn Differential Revision: https://reviews.llvm.org/D48220 llvm-svn: 334983
OpenPOWER on IntegriCloud