summaryrefslogtreecommitdiffstats
path: root/llvm/test/Verifier
Commit message (Collapse)AuthorAgeFilesLines
* Add function attribute "patchable-function-prefix" to support ↵Fangrui Song2020-01-241-0/+10
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | -fpatchable-function-entry=N,M where M>0 Similar to the function attribute `prefix` (prefix data), "patchable-function-prefix" inserts data (M NOPs) before the function entry label. -fpatchable-function-entry=2,1 (1 NOP before entry, 1 NOP after entry) will look like: ``` .type foo,@function .Ltmp0: # @foo nop foo: .Lfunc_begin0: # optional `bti c` (AArch64 Branch Target Identification) or # `endbr64` (Intel Indirect Branch Tracking) nop .section __patchable_function_entries,"awo",@progbits,get,unique,0 .p2align 3 .quad .Ltmp0 ``` -fpatchable-function-entry=N,0 + -mbranch-protection=bti/-fcf-protection=branch has two reasonable placements (https://gcc.gnu.org/ml/gcc-patches/2020-01/msg01185.html): ``` (a) (b) func: func: .Ltmp0: bti c bti c .Ltmp0: nop nop ``` (a) needs no additional code. If the consensus is to go for (b), we will need more code in AArch64BranchTargets.cpp / X86IndirectBranchTracking.cpp . Differential Revision: https://reviews.llvm.org/D73070 (cherry picked from commit 22467e259507f5ead2a87d989251b4c951a587e4)
* [AArch64] Add function attribute "patchable-function-entry" to add NOPs at ↵Fangrui Song2020-01-101-0/+11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | function entry The Linux kernel uses -fpatchable-function-entry to implement DYNAMIC_FTRACE_WITH_REGS for arm64 and parisc. GCC 8 implemented -fpatchable-function-entry, which can be seen as a generalized form of -mnop-mcount. The N,M form (function entry points before the Mth NOP) is currently only used by parisc. This patch adds N,0 support to AArch64 codegen. N is represented as the function attribute "patchable-function-entry". We will use a different function attribute for M, if we decide to implement it. The patch reuses the existing patchable-function pass, and TargetOpcode::PATCHABLE_FUNCTION_ENTER which is currently used by XRay. When the integrated assembler is used, __patchable_function_entries will be created for each text section with the SHF_LINK_ORDER flag to prevent --gc-sections (https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93197) and COMDAT (https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93195) issues. Retrospectively, __patchable_function_entries should use a PC-relative relocation type to avoid the SHF_WRITE flag and dynamic relocations. "patchable-function-entry"'s interaction with Branch Target Identification is still unclear (see https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92424 for GCC discussions). Reviewed By: peter.smith Differential Revision: https://reviews.llvm.org/D72215
* Verifier: Check frame-pointer attribute valuesMatt Arsenault2019-12-113-0/+27
| | | | | | There are a few places that check specific string attributes have particular values, and assert if they are something else. The verifier should catch these kinds of cases.
* [DebugInfo] Add a DW_OP_LLVM_entry_value operationDavid Stenberg2019-10-154-4/+48
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: Internally in LLVM's metadata we use DW_OP_entry_value operations with the same semantics as DWARF; that is, its operand specifies the number of bytes that the entry value covers. At the time of emitting entry values we don't know the emitted size of the DWARF expression that the entry value will cover. Currently the size is hardcoded to 1 in DIExpression, and other values causes the verifier to fail. As the size is 1, that effectively means that we can only have valid entry values for registers that can be encoded in one byte, which are the registers with DWARF numbers 0 to 31 (as they can be encoded as single-byte DW_OP_reg0..DW_OP_reg31 rather than a multi-byte DW_OP_regx). It is a bit confusing, but it seems like llvm-dwarfdump will print an operation "correctly", even if the byte size is less than that, which may make it seem that we emit correct DWARF for registers with DWARF numbers > 31. If you instead use readelf for such cases, it will interpret the number of specified bytes as a DWARF expression. This seems like a limitation in llvm-dwarfdump. As suggested in D66746, a way forward would be to add an internal variant of DW_OP_entry_value, DW_OP_LLVM_entry_value, whose operand instead specifies the number of operations that the entry value covers, and we then translate that into the byte size at the time of emission. In this patch that internal operation is added. This patch keeps the limitation that a entry value can only be applied to simple register locations, but it will fix the issue with the size operand being incorrect for DWARF numbers > 31. Reviewers: aprantl, vsk, djtodoro, NikolaPrica Reviewed By: aprantl Subscribers: jyknight, fedor.sergeev, hiraditya, llvm-commits Tags: #debug-info, #llvm Differential Revision: https://reviews.llvm.org/D67492 llvm-svn: 374881
* [FPEnv] Strict FP tests should use the requisite function attributes.Kevin P. Neal2019-10-041-12/+14
| | | | | | | | | | | | | | | A set of function attributes is required in any function that uses constrained floating point intrinsics. None of our tests use these attributes. This patch fixes this. These tests have been tested against the IR verifier changes in D68233. Reviewed by: andrew.w.kaylor, cameron.mcinally, uweigand Approved by: andrew.w.kaylor Differential Revision: https://reviews.llvm.org/D67925 llvm-svn: 373761
* [Verifier] add invariant check for callbrNick Desaulniers2019-09-251-0/+50
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: The list of indirect labels should ALWAYS have their blockaddresses as argument operands to the callbr (but not necessarily the other way around). Add an invariant that checks this. The verifier catches a bad test case that was added recently in r368478. I think that was a simple mistake, and the test was made less strict in regards to the precise addresses (as those weren't specifically the point of the test). This invariant will be used to find a reported bug. Link: https://www.spinics.net/lists/arm-kernel/msg753473.html Link: https://github.com/ClangBuiltLinux/linux/issues/649 Reviewers: craig.topper, void, chandlerc Reviewed By: void Subscribers: ychen, lebedev.ri, javed.absar, kristof.beyls, hiraditya, llvm-commits, srhines Tags: #llvm Differential Revision: https://reviews.llvm.org/D67196 llvm-svn: 372923
* [Mips] Remove immarg test for intrinsics that no longer have an immarg after ↵Craig Topper2019-09-201-82/+0
| | | | | | r372409. llvm-svn: 372420
* Remove the obsolete BlockByRefStruct flag from LLVM IRAdrian Prantl2019-09-181-2/+2
| | | | | | | | | | | | | | | | | | | | | | | DIFlagBlockByRefStruct is an unused DIFlag that originally was used by clang to express (Objective-)C block captures in debug info. For the last year Clang has been emitting complex DIExpressions to describe block captures instead, which makes all the code supporting this flag redundant. This patch removes the flag and all supporting "dead" code, so we can reuse the bit for something else in the future. Since this only affects debug info generated by Clang with the block extension this mostly affects Apple platforms and I don't have any bitcode compatibility concerns for removing this. The Verifier will reject debug info that uses the bit and thus degrade gracefully when LTO'ing older bitcode with a newer compiler. rdar://problem/44304813 Differential Revision: https://reviews.llvm.org/D67453 llvm-svn: 372272
* [Intrinsic] Add the llvm.umul.fix.sat intrinsicBjorn Pettersson2019-09-071-0/+18
| | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: Add an intrinsic that takes 2 unsigned integers with the scale of them provided as the third argument and performs fixed point multiplication on them. The result is saturated and clamped between the largest and smallest representable values of the first 2 operands. This is a part of implementing fixed point arithmetic in clang where some of the more complex operations will be implemented as intrinsics. Patch by: leonardchan, bjope Reviewers: RKSimon, craig.topper, bevinh, leonardchan, lebedev.ri, spatel Reviewed By: leonardchan Subscribers: ychen, wuzish, nemanjai, MaskRay, jsji, jdoerfert, Ka-Ka, hiraditya, rjmccall, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D57836 llvm-svn: 371308
* [IntrinsicEmitter] Support scalable vectors in intrinsicsCullen Rhodes2019-08-271-0/+10
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: This patch adds support for scalable vectors in intrinsics, enabling intrinsics such as the following to be defined: declare <vscale x 4 x i32> @llvm.something.nxv4i32(<vscale x 4 x i32>) Support for this is implemented by defining a new type descriptor for scalable vectors and adding mangling support for scalable vector types in the name mangling scheme used by 'any' types in intrinsic signatures. Tests have been added for IRBuilder to test scalable vectors work as expected when using intrinsics through this interface. This required implementing an intrinsic that is explicitly defined with scalable vectors, e.g. LLVMType<nxv4i32>, an SVE floating-point convert intrinsic was used for this. The behaviour of the overloaded type LLVMScalarOrSameVectorWidth with scalable vectors is tested using the existing masked load intrinsic. Also added an .ll test to test the Verifier catches a bad intrinsic argument when passing a fixed-width predicate (mask) to the masked.load intrinsic where a scalable is expected. Patch by Paul Walker Reviewed By: sdesmalen Differential Revision: https://reviews.llvm.org/D65930 llvm-svn: 370053
* IR: Disable verifier check for GlobalValues with private linkage named after ↵Peter Collingbourne2019-08-061-1/+3
| | | | | | | | | | | a comdat for non-COFF. This check is only meaningful for COFF and it is perfectly valid to create such a GlobalValue in ELF. Differential Revision: https://reviews.llvm.org/D65686 llvm-svn: 368094
* [FunctionAttrs] Annotate "willreturn" for intrinsicsHideto Ueno2019-07-281-1/+1
| | | | | | | | | | | | | | | | | | | Summary: In D62801, new function attribute `willreturn` was introduced. In short, a function with `willreturn` is guaranteed to come back to the call site(more precise definition is in LangRef). In this patch, willreturn is annotated for LLVM intrinsics. Reviewers: jdoerfert Reviewed By: jdoerfert Subscribers: jvesely, nhaehnle, sstefan1, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D64904 llvm-svn: 367184
* Allow prefetching from non-zero address spacesJF Bastien2019-07-251-1/+1
| | | | | | | | | | | | | | | Summary: This is useful for targets which have prefetch instructions for non-default address spaces. <rdar://problem/42662136> Subscribers: nemanjai, javed.absar, hiraditya, kbarton, jkorous, dexonsmith, cfe-commits, llvm-commits, RKSimon, hfinkel, t.p.northover, craig.topper, anemet Tags: #clang, #llvm Differential Revision: https://reviews.llvm.org/D65254 llvm-svn: 367032
* [IR][Verifier] Allow IntToPtrInst to be !dereferenceableRyan Taylor2019-07-232-3/+51
| | | | | | | | | | | | | | | | | Summary: Allow IntToPtrInst to carry !dereferenceable metadata tag. This is valid since !dereferenceable can be only be applied to pointer type values. Change-Id: If8a6e3c616f073d51eaff52ab74535c29ed497b4 Subscribers: llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D64954 llvm-svn: 366826
* Added address-space mangling for stack related intrinsicsChristudasan Devadasan2019-07-221-1/+1
| | | | | | | | | | | | Modified the following 3 intrinsics: int_addressofreturnaddress, int_frameaddress & int_sponentry. Reviewed By: arsenm Differential Revision: https://reviews.llvm.org/D64561 llvm-svn: 366679
* ARM: Fix missing immarg for space intrinsicMatt Arsenault2019-07-161-0/+9
| | | | llvm-svn: 366280
* AMDGPU: Fix missing immarg for mfma intrinsicsMatt Arsenault2019-07-161-0/+23
| | | | llvm-svn: 366230
* AMDGPU: Fix missing immarg from interp intrinsicsMatt Arsenault2019-07-151-0/+96
| | | | llvm-svn: 366110
* [SystemZ] Add support for new cpu architecture - arch13Ulrich Weigand2019-07-121-0/+18
| | | | | | | | | | | | | | | | | | This patch series adds support for the next-generation arch13 CPU architecture to the SystemZ backend. This includes: - Basic support for the new processor and its features. - Assembler/disassembler support for new instructions. - CodeGen for new instructions, including new LLVM intrinsics. - Scheduler description for the new processor. - Detection of arch13 as host processor. Note: No currently available Z system supports the arch13 architecture. Once new systems become available, the official system name will be added as supported -march name. llvm-svn: 365932
* Scalable Vector IR Type with further LTO fixesGraham Hunter2019-07-051-0/+12
| | | | | | | | | | | | | | | | | Reintroduces the scalable vector IR type from D32530, after it was reverted a couple of times due to increasing chromium LTO build times. This latest incarnation removes the walk over aggregate types from the verifier entirely, in favor of rejecting scalable vectors in the isValidElementType methods in ArrayType and StructType. This removes the 70% degradation observed with the second repro tarball from PR42210. Reviewers: thakis, hans, rengolin, sdesmalen Reviewed By: sdesmalen Differential Revision: https://reviews.llvm.org/D64079 llvm-svn: 365203
* Revert r363658 "[SVE][IR] Scalable Vector IR Type with pr42210 fix"Hans Wennborg2019-06-272-53/+0
| | | | | | | | | | | | | | | | | | | | | | | | We saw a 70% ThinLTO link time increase in Chromium for Android, see crbug.com/978817. Sounds like more of PR42210. > Recommit of D32530 with a few small changes: > - Stopped recursively walking through aggregates in > the verifier, so that we don't impose too much > overhead on large modules under LTO (see PR42210). > - Changed tests to match; the errors are slightly > different since they only report the array or > struct that actually contains a scalable vector, > rather than all aggregates which contain one in > a nested member. > - Corrected an older comment > > Reviewers: thakis, rengolin, sdesmalen > > Reviewed By: sdesmalen > > Differential Revision: https://reviews.llvm.org/D63321 llvm-svn: 364543
* [DWARF] Handle the DW_OP_entry_value operandDjordje Todorovic2019-06-272-0/+12
| | | | | | | | | | | | | | | Add the IR and the AsmPrinter parts for handling of the DW_OP_entry_values DWARF operation. ([11/13] Introduce the debug entry values.) Co-authored-by: Ananth Sowda <asowda@cisco.com> Co-authored-by: Nikola Prica <nikola.prica@rt-rk.com> Co-authored-by: Ivan Baev <ibaev@cisco.com> Differential Revision: https://reviews.llvm.org/D60866 llvm-svn: 364542
* [IR] Add DISuprogram and DIE for a func declDjordje Todorovic2019-06-271-2/+7
| | | | | | | | | | | | | | | A unique DISubprogram may be attached to a function declaration used for call site debug info. ([6/13] Introduce the debug entry values.) Co-authored-by: Ananth Sowda <asowda@cisco.com> Co-authored-by: Nikola Prica <nikola.prica@rt-rk.com> Co-authored-by: Ivan Baev <ibaev@cisco.com> Differential Revision: https://reviews.llvm.org/D60713 llvm-svn: 364500
* Add debug location verification for !llvm.loop attachments.Adrian Prantl2019-06-181-0/+28
| | | | | | | | | | | | | | | | This patch teaches the Verifier how to detect broken !llvm.loop attachments as discussed in https://reviews.llvm.org/D60831. This allows LLVM to warn and strip out the broken debug info before attempting an LTO compilation with input generated by LLVM predating https://reviews.llvm.org/rL361149. rdar://problem/51631158 Differential Revision: https://reviews.llvm.org/D63499 [Re-applies r363725 without changes after fixing a broken testcase.] llvm-svn: 363731
* Revert Add debug location verification for !llvm.loop attachments.Adrian Prantl2019-06-181-28/+0
| | | | | | This reverts r363725 (git commit 8ff822d61dacf5a9466755eedafd3eeb54abc00d) llvm-svn: 363728
* Add debug location verification for !llvm.loop attachments.Adrian Prantl2019-06-181-0/+28
| | | | | | | | | | | | | | This patch teaches the Verifier how to detect broken !llvm.loop attachments as discussed in https://reviews.llvm.org/D60831. This allows LLVM to warn and strip out the broken debug info before attempting an LTO compilation with input generated by LLVM predating https://reviews.llvm.org/rL361149. rdar://problem/51631158 Differential Revision: https://reviews.llvm.org/D63499 llvm-svn: 363725
* [SVE][IR] Scalable Vector IR Type with pr42210 fixGraham Hunter2019-06-182-0/+53
| | | | | | | | | | | | | | | | | | | | | Recommit of D32530 with a few small changes: - Stopped recursively walking through aggregates in the verifier, so that we don't impose too much overhead on large modules under LTO (see PR42210). - Changed tests to match; the errors are slightly different since they only report the array or struct that actually contains a scalable vector, rather than all aggregates which contain one in a nested member. - Corrected an older comment Reviewers: thakis, rengolin, sdesmalen Reviewed By: sdesmalen Differential Revision: https://reviews.llvm.org/D63321 llvm-svn: 363658
* Test forward references in IntrinsicEmitter on Neon LD(2|3|4)Sander de Smalen2019-06-171-0/+79
| | | | | | | | | | | | | | | | | | | | This patch tests the forward-referencing added in D62995 by changing some existing intrinsics to use forward referencing of overloadable parameters, rather than backward referencing. This patch changes the TableGen definition/implementation of llvm.aarch64.neon.ld2lane and llvm.aarch64.neon.ld2lane intrinsics (and similar for ld3 and ld4). This change is intended to be non-functional, since the behaviour of the intrinsics is expected to be the same. Reviewers: arsenm, dmgreen, RKSimon, greened, rnk Reviewed By: RKSimon Differential Revision: https://reviews.llvm.org/D63189 llvm-svn: 363546
* [AMDGPU] gfx1010 wave32 icmp/fcmp intrinsic changes for wave32Stanislav Mekhanoshin2019-06-131-6/+6
| | | | | | Differential Revision: https://reviews.llvm.org/D63301 llvm-svn: 363339
* [AMDGPU] ImmArg and SourceOfDivergence for permlane/dppStanislav Mekhanoshin2019-06-131-0/+28
| | | | | | | | | Added missing ImmArg and SourceOfDivergence to the crosslane intrinsics. Differential Revision: https://reviews.llvm.org/D63216 llvm-svn: 363276
* Revert r361953 "[SVE][IR] Scalable Vector IR Type"Nico Weber2019-06-092-55/+0
| | | | | | | This reverts commit f4fc01f8dd3a5dfd2060d1ad0df6b90e8351ddf7. It caused a 3-4x slowdown when doing thinlto links, PR42210. llvm-svn: 362913
* [SVE][IR] Scalable Vector IR TypeGraham Hunter2019-05-292-0/+55
| | | | | | | | | | | | | | | | | | | * Adds a 'scalable' flag to VectorType * Adds an 'ElementCount' class to VectorType to pass (possibly scalable) vector lengths, with overloaded operators. * Modifies existing helper functions to use ElementCount * Adds support for serializing/deserializing to/from both textual and bitcode IR formats * Extends the verifier to reject global variables of scalable types * Updates documentation See the latest version of the RFC here: http://lists.llvm.org/pipermail/llvm-dev/2018-July/124396.html Reviewers: rengolin, lattner, echristo, chandlerc, hfinkel, rkruppe, samparker, SjoerdMeijer, greened, sebpop Reviewed By: hfinkel, sebpop Differential Revision: https://reviews.llvm.org/D32530 llvm-svn: 361953
* [IR] Disallow llvm.global_ctors and llvm.global_dtors of the 2-field form in ↵Fangrui Song2019-05-151-0/+6
| | | | | | | | | | | | | | | | | | | | textual format The 3-field form was introduced by D3499 in 2014 and the legacy 2-field form was planned to be removed in LLVM 4.0 For the textual format, this patch migrates the existing 2-field form to use the 3-field form and deletes the compatibility code. test/Verifier/global-ctors-2.ll checks we have a friendly error message. For bitcode, lib/IR/AutoUpgrade UpgradeGlobalVariables will upgrade the 2-field form (add i8* null as the third field). Reviewed By: rnk, dexonsmith Differential Revision: https://reviews.llvm.org/D61547 llvm-svn: 360742
* Debug Info: Support address space attributes on rvalue references.Adrian Prantl2019-05-071-2/+2
| | | | | | | | | | | | | | | | | | | DWARF5, 2.12 20ff says that Any debugging information entry representing a pointer or reference type [may have a DW_AT_address_class attribute]. The existing code (https://reviews.llvm.org/D29670) seems to take a quite literal interpretation of that wording. I don't see a reason why an rvalue reference isn't a reference type in the spirit of that paragraph. This patch allows rvalue references to also have address spaces. rdar://problem/50511483 Differential Revision: https://reviews.llvm.org/D61625 llvm-svn: 360176
* [SystemZ] Add missing intrinsics to intrinsics-immarg.llUlrich Weigand2019-04-161-0/+217
| | | | | | | | | | As of r356091, support for the ImmArg intrinsics was added, including a SystemZ test case. However, that test case doesn't actually verify all SystemZ intrinsics with immediate arguments, only a subset. The rest of them actually works correctly, there's just no test for them. This patch add all missing intrinsics. llvm-svn: 358495
* Remove immarg from llvm.expectMatt Arsenault2019-03-171-9/+0
| | | | | | | | | The LangRef claimed this was required to be a constant, but this appears to be wrong. Fixes bug 41079. llvm-svn: 356353
* ARM: Add ImmArg to intrinsicsMatt Arsenault2019-03-142-0/+104
| | | | | | | | | | I found these by asserting in clang for any GCCBuiltin that doesn't require mangling and requires a constant for the builtin. This means that intrinsics are missing which don't use GCCBuiltin, don't have builtins defined in clang, or were missing the constant annotation in the builtin definition. llvm-svn: 356144
* Verifier: Make sure masked load/store alignment is a power of 2Matt Arsenault2019-03-132-0/+20
| | | | | | | The same should also be done for scatter/gather, but the verifier doesn't check those at all now. llvm-svn: 356094
* SystemZ: Add ImmArg to intrinsicsMatt Arsenault2019-03-132-0/+168
| | | | | | | | | | I found these by asserting in clang for any GCCBuiltin that doesn't require mangling and requires a constant for the builtin. This means that intrinsics are missing which don't use GCCBuiltin, don't have builtins defined in clang, or were missing the constant annotation in the builtin definition. llvm-svn: 356091
* Mips: Add ImmArg to intrinsicsMatt Arsenault2019-03-132-0/+84
| | | | | | | | | | | | | | | I found these by asserting in clang for any GCCBuiltin that doesn't require mangling and requires a constant for the builtin. This means that intrinsics are missing which don't use GCCBuiltin, don't have builtins defined in clang, or were missing the constant annotation in the builtin definition. I'm not sure what's going on with the immediates.ll test. It seems to be intended to test invalid cases like this, but then tries to handle some of them anyway. I've moved the cases that were inconsistent with the GCCBuiltin definition so they don't test the codegen anymore. llvm-svn: 356085
* IR: Add immarg attributeMatt Arsenault2019-03-127-6/+906
| | | | | | | | | | | | | | | | | This indicates an intrinsic parameter is required to be a constant, and should not be replaced with a non-constant value. Add the attribute to all AMDGPU and generic intrinsics that comments indicate it should apply to. I scanned other target intrinsics, but I don't see any obvious comments indicating which arguments are intended to be only immediates. This breaks one questionable testcase for the autoupgrade. I'm unclear on whether the autoupgrade is supposed to really handle declarations which were never valid. The verifier fails because the attributes now refer to a parameter past the end of the argument list. llvm-svn: 355981
* [llvm] Fix typo: 's/ ot / to /' [NFC]Mandeep Singh Grang2019-02-211-1/+1
| | | | llvm-svn: 354614
* Try to organize MachineVerifier testsMatt Arsenault2019-02-1524-912/+0
| | | | | | | | | | The Verifier is separate from the MachineVerifier, so move it to a different directory. Some other verifier tests were scattered in target codegen tests as well (although I'm sure I missed some). Work towards using a more consistent naming scheme to make it clearer where the gaps still are for generic instructions. llvm-svn: 354138
* Replace gcroot verifier testsMatt Arsenault2019-02-144-44/+52
| | | | | | | | These haven't been checking anything useful and have been testing the wrong failure reason for many years. Replace them with something which stresses what is actually implemented in the verifier now. llvm-svn: 354070
* GlobalISel: Verify G_EXTRACTMatt Arsenault2019-02-111-0/+35
| | | | llvm-svn: 353759
* GlobalISel: Verify G_GEPMatt Arsenault2019-02-051-0/+32
| | | | llvm-svn: 353209
* GlobalISel: Fix verifier crashing on non-register operandsMatt Arsenault2019-02-051-1/+10
| | | | | | Also correct the wording of error on subregisters. llvm-svn: 353128
* GlobalISel: Enforce operand types for constantsMatt Arsenault2019-02-043-5/+49
| | | | | | | | A number of of tests were using imm operands, not cimm. Since CSE relies on the exact ConstantInt* pointer used, and implicit conversions are generally evil, also enforce the bitsize of the types. llvm-svn: 353113
* GlobalISel: Verify g_selectMatt Arsenault2019-02-044-11/+42
| | | | | | | Factor the common vector element consistency check many instructions need out, although this makes the error messages worse. llvm-svn: 353112
* GlobalISel: Verify memory size for load/storeMatt Arsenault2019-01-302-1/+11
| | | | llvm-svn: 352578
OpenPOWER on IntegriCloud