summaryrefslogtreecommitdiffstats
path: root/llvm/test/MachineVerifier
Commit message (Collapse)AuthorAgeFilesLines
* Recommit "[MachineVerifier] Improve verification of live-in lists."Jonas Paulsson2020-01-083-0/+125
| | | | | | | | | | | | | | | | | | MachineVerifier::visitMachineFunctionAfter() is extended to check the live-through case for live-in lists. This is only done for registers without aliases and that are neither allocatable or reserved, such as the SystemZ::CC register. The MachineVerifier earlier only catched the case of a live-in use without an entry in the live-in list (as "using an undefined physical register"). A comment in LivePhysRegs.h has been added stating a guarantee that addLiveOuts() can be trusted for a full register both before and after register allocation. Review: Quentin Colombet Differential Revision: https://reviews.llvm.org/D68267
* [MachineVerifier] Improve checks of target instructions operands.Jonas Paulsson2019-12-031-0/+37
| | | | | | | | | | | | | | | | While working with a patch for instruction selection, the splitting of a large immediate ended up begin treated incorrectly by the backend. Where a register operand should have been created, it instead became an immediate. To my surprise the machine verifier failed to report this, which at the time would have been helpful. This patch improves the verifier so that it will report this type of error. This patch XFAILs CodeGen/SPARC/fp128.ll, which has been reported at https://bugs.llvm.org/show_bug.cgi?id=44091 Review: thegameg, arsenm, fhahn https://reviews.llvm.org/D63973
* Revert "[MachineVerifier] Improve verification of live-in lists.Galina Kistanova2019-11-073-125/+0
| | | | This reverts commit b7b170c to give the author more time to address failing tests on the expensive checks buildbots.
* [globalisel] Rename G_GEP to G_PTR_ADDDaniel Sanders2019-11-051-5/+5
| | | | | | | | | | | | | | | | Summary: G_GEP is rather poorly named. It's a simple pointer+scalar addition and doesn't support any of the complexities of getelementptr. I therefore propose that we rename it. There's a G_PTR_MASK so let's follow that convention and go with G_PTR_ADD Reviewers: volkan, aditya_nandakumar, bogner, rovka, arsenm Subscribers: sdardis, jvesely, wdng, nhaehnle, hiraditya, jrtc27, atanasyan, arphaman, Petar.Avramovic, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D69734
* Fix buildbots troubled by b7b170c.Jonas Paulsson2019-11-043-0/+3
| | | | Add '# REQUIRES: systemz-registered-target' in the new tests.
* [MachineVerifier] Improve verification of live-in lists.Jonas Paulsson2019-11-043-0/+122
| | | | | | | | | | | | | | | | | MachineVerifier::visitMachineFunctionAfter() is extended to check the live-through case for live-in lists. This is only done for registers without aliases and that are neither allocatable or reserved, such as the SystemZ::CC register. The MachineVerifier earlier only catched the case of a live-in use without an entry in the live-in list (as "using an undefined physical register"). A comment in LivePhysRegs.h has been added stating a guarantee that addLiveOuts() can be trusted for a full register both before and after register allocation. Review: Quentin Colombet https://reviews.llvm.org/D68267
* Add an operand to memory intrinsics to denote the "tail" marker.Amara Emerson2019-09-281-0/+27
| | | | | | | | | | | | | | We need to propagate this information from the IR in order to be able to safely do tail call optimizations on the intrinsics during legalization. Assuming it's safe to do tail call opt without checking for the marker isn't safe because the mem libcall may use allocas from the caller. This adds an extra immediate operand to the end of the intrinsics and fixes the legalizer to handle it. Differential Revision: https://reviews.llvm.org/D68151 llvm-svn: 373140
* Remove unnecessary REQUIRES from a test.Amara Emerson2019-08-241-1/+1
| | | | llvm-svn: 369835
* [GlobalISel] Introduce a G_DYN_STACKALLOC opcode to represent dynamic allocas.Amara Emerson2019-08-241-0/+25
| | | | | | | | | This just adds the opcode and verifier, it will be used to replace existing dynamic alloca handling in a subsequent patch. Differential Revision: https://reviews.llvm.org/D66677 llvm-svn: 369833
* [GlobalISel]: Fix lowering of G_SHUFFLE_VECTOR with scalar sourcesAditya Nandakumar2019-08-131-0/+4
| | | | | | https://reviews.llvm.org/D66171 llvm-svn: 368753
* GlobalISel: Add more verifier checks for G_SHUFFLE_VECTORMatt Arsenault2019-08-131-1/+27
| | | | llvm-svn: 368705
* GlobalISel: Change representation of shuffle masksMatt Arsenault2019-08-131-0/+29
| | | | | | | | | | | | | | | | | | Currently shufflemasks get emitted as any other constant, and you end up with a bunch of virtual registers of G_CONSTANT with a G_BUILD_VECTOR. The AArch64 selector then asserts on anything that doesn't fit this pattern. This isn't an ideal representation, and should avoid legalization and have fewer opportunities for a representational error. Rather than invent a new shuffle mask operand type, similar to what ShuffleVectorSDNode does, just track the original IR Constant mask operand. I don't completely like the idea of adding another link to the IR, but MIR is already quite dependent on IR constants already, and this will allow sharing the shuffle mask utility functions with the IR. llvm-svn: 368704
* Add missing REQUIRES to r368487Daniel Sanders2019-08-091-0/+1
| | | | llvm-svn: 368494
* [globalisel] Add G_SEXT_INREGDaniel Sanders2019-08-091-0/+53
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: Targets often have instructions that can sign-extend certain cases faster than the equivalent shift-left/arithmetic-shift-right. Such cases can be identified by matching a shift-left/shift-right pair but there are some issues with this in the context of combines. For example, suppose you can sign-extend 8-bit up to 32-bit with a target extend instruction. %1:_(s32) = G_SHL %0:_(s32), i32 24 # (I've inlined the G_CONSTANT for brevity) %2:_(s32) = G_ASHR %1:_(s32), i32 24 %3:_(s32) = G_ASHR %2:_(s32), i32 1 would reasonably combine to: %1:_(s32) = G_SHL %0:_(s32), i32 24 %2:_(s32) = G_ASHR %1:_(s32), i32 25 which no longer matches the special case. If your shifts and extend are equal cost, this would break even as a pair of shifts but if your shift is more expensive than the extend then it's cheaper as: %2:_(s32) = G_SEXT_INREG %0:_(s32), i32 8 %3:_(s32) = G_ASHR %2:_(s32), i32 1 It's possible to match the shift-pair in ISel and emit an extend and ashr. However, this is far from the only way to break this shift pair and make it hard to match the extends. Another example is that with the right known-zeros, this: %1:_(s32) = G_SHL %0:_(s32), i32 24 %2:_(s32) = G_ASHR %1:_(s32), i32 24 %3:_(s32) = G_MUL %2:_(s32), i32 2 can become: %1:_(s32) = G_SHL %0:_(s32), i32 24 %2:_(s32) = G_ASHR %1:_(s32), i32 23 All upstream targets have been configured to lower it to the current G_SHL,G_ASHR pair but will likely want to make it legal in some cases to handle their faster cases. To follow-up: Provide a way to legalize based on the constant. At the moment, I'm thinking that the best way to achieve this is to provide the MI in LegalityQuery but that opens the door to breaking core principles of the legalizer (legality is not context sensitive). That said, it's worth noting that looking at other instructions and acting on that information doesn't violate this principle in itself. It's only a violation if, at the end of legalization, a pass that checks legality without being able to see the context would say an instruction might not be legal. That's a fairly subtle distinction so to give a concrete example, saying %2 in: %1 = G_CONSTANT 16 %2 = G_SEXT_INREG %0, %1 is legal is in violation of that principle if the legality of %2 depends on %1 being constant and/or being 16. However, legalizing to either: %2 = G_SEXT_INREG %0, 16 or: %1 = G_CONSTANT 16 %2:_(s32) = G_SHL %0, %1 %3:_(s32) = G_ASHR %2, %1 depending on whether %1 is constant and 16 does not violate that principle since both outputs are genuinely legal. Reviewers: bogner, aditya_nandakumar, volkan, aemerson, paquette, arsenm Subscribers: sdardis, jvesely, wdng, nhaehnle, rovka, kristof.beyls, javed.absar, hiraditya, jrtc27, atanasyan, Petar.Avramovic, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D61289 llvm-svn: 368487
* [Testing] Fix tests that break with read-only checkoutsDavid Zarzycki2019-08-011-1/+1
| | | | | | Found with `mount --bind -o ro ...` on Linux. llvm-svn: 367519
* GlobalISel: Verify G_MERGE_VALUES operand sizesMatt Arsenault2019-07-011-0/+28
| | | | llvm-svn: 364822
* Fix GlobalISel MachineVerifier tests. NFC.Volkan Keles2019-06-1914-14/+14
| | | | | | | | These test were failing when building llvm with `-DLLVM_DEFAULT_TARGET_TRIPLE=''`. Add `-march` to the run line to fix the issue. llvm-svn: 363854
* GlobalISel: Verify intrinsicsMatt Arsenault2019-06-172-0/+73
| | | | | | | | I keep using the wrong instruction when manually writing tests. This really needs to check the number of operands, but I don't see an easy way to do that right now. llvm-svn: 363579
* [GlobalISel] Add a G_BRJT opcode.Amara Emerson2019-06-141-0/+30
| | | | | | | | | | | | | This is a branch opcode that takes a jump table pointer, jump table index and an index into the table to do an indirect branch. We pass both the table pointer and JTI to allow targets like ARM64 to more easily use the existing jump table compression optimization without having to walk up the block to find a paired G_JUMP_TABLE. Differential Revision: https://reviews.llvm.org/D63159 llvm-svn: 363434
* [GlobalISel] Add a G_JUMP_TABLE opcode.Amara Emerson2019-06-111-0/+26
| | | | | | | | | | | | This opcode generates a pointer to the address of the jump table specified by the source operand, which is a jump table index. It will be used in conjunction with an upcoming G_BRJT opcode to support jump table codegen with GlobalISel. Differential Revision: https://reviews.llvm.org/D63111 llvm-svn: 363096
* [X86] Merge the different Jcc instructions for each condition code into ↵Craig Topper2019-04-052-3/+3
| | | | | | | | | | | | | | | | | | | | | single instructions that store the condition code as an operand. Summary: This avoids needing an isel pattern for each condition code. And it removes translation switches for converting between Jcc instructions and condition codes. Now the printer, encoder and disassembler take care of converting the immediate. We use InstAliases to handle the assembly matching. But we print using the asm string in the instruction definition. The instruction itself is marked IsCodeGenOnly=1 to hide it from the assembly parser. Reviewers: spatel, lebedev.ri, courbet, gchatelet, RKSimon Reviewed By: RKSimon Subscribers: MatzeB, qcolombet, eraman, hiraditya, arphaman, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D60228 llvm-svn: 357802
* [AMDGPU] Add support for immediate operand for S_ENDPGMDavid Stuttard2019-03-121-3/+3
| | | | | | | | | | | | | | | | | Summary: Add support for immediate operand in S_ENDPGM Change-Id: I0c56a076a10980f719fb2a8f16407e9c301013f6 Reviewers: alexshap Subscribers: qcolombet, arsenm, kzhuravl, jvesely, wdng, nhaehnle, yaxunl, tpr, t-tye, eraman, arphaman, Petar.Avramovic, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D59213 llvm-svn: 355902
* GlobalISel: Verify g_insertMatt Arsenault2019-02-191-0/+44
| | | | llvm-svn: 354342
* GlobalISel: Fix inadequate verification of g_build_vectorMatt Arsenault2019-02-151-18/+32
| | | | | | | | | | | | | Testing based on the total size of the elements failed to catch a few invalid scenarios, so explicitly check the number of elements/operands and types. This failed to catch situations like <4 x s16> = G_BUILD_VECTOR s32, s32 since the total size added up. This also would fail to catch an implicit conversion between pointers and scalars. llvm-svn: 354139
* Try to organize MachineVerifier testsMatt Arsenault2019-02-1533-0/+1223
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
OpenPOWER on IntegriCloud