summaryrefslogtreecommitdiffstats
path: root/llvm/test/CodeGen/AArch64/GlobalISel
Commit message (Collapse)AuthorAgeFilesLines
* GlobalISel: add G_IMPLICIT_DEF instruction.Tim Northover2017-06-305-17/+47
| | | | | | | | | It looks like there are two target-independent but not GISel instructions that need legalization, IMPLICIT_DEF and PHI. These are already anomalies since their operands have important LLTs attached, so to make things more uniform it seems like a good idea to add generic variants. Starting with G_IMPLICIT_DEF. llvm-svn: 306875
* [GISel]: New Opcode G_FLOG/G_FLOG2Aditya Nandakumar2017-06-291-0/+19
| | | | | | https://reviews.llvm.org/D34837 llvm-svn: 306766
* [GISel]: Add G_FEXP, G_FEXP2 opcodesAditya Nandakumar2017-06-271-0/+20
| | | | | | | Also add IRTranslator support. https://reviews.llvm.org/D34710 llvm-svn: 306475
* GlobalISel: verify that a COPY is trivial when created.Tim Northover2017-06-271-1/+1
| | | | | | | | | | | | Without this check, COPY instructions can actually be one of the generic casts in disguise. That's confusing and bad. At some point during ISel this restriction has to be relaxed since the fully selected instructions will usually use COPY for those purposes. Right now I think it's possible that relaxation occurs during RegBankSelect (hence the change there). I'm not convinced that's where it belongs long-term though. llvm-svn: 306470
* [globalisel][tablegen] Add support for EXTRACT_SUBREG.Daniel Sanders2017-06-271-2/+2
| | | | | | | | | | | | | | | | Summary: After this patch, we finally have test cases that require multiple instruction emission. Depends on D33590 Reviewers: ab, qcolombet, t.p.northover, rovka, kristof.beyls Subscribers: javed.absar, llvm-commits, igorb Differential Revision: https://reviews.llvm.org/D33596 llvm-svn: 306388
* AArch64: legalize G_EXTRACT operations.Tim Northover2017-06-263-8/+92
| | | | | | | This is the dual problem to legalizing G_INSERTs so most of the code and testing was cribbed from there. llvm-svn: 306328
* GlobalISel: remove G_SEQUENCE instruction.Tim Northover2017-06-232-41/+13
| | | | | | | | It was trying to do too many things. The basic lumping together of values for legalization purposes is now handled by G_MERGE_VALUES. More complex things involving gaps and odd sizes are handled by G_INSERT sequences. llvm-svn: 306120
* GlobalISel: convert buildSequence to use non-deprecated instructions.Tim Northover2017-06-232-7/+19
| | | | | | | | G_SEQUENCE is going away soon so as a first step the MachineIRBuilder needs to be taught how to emulate it with alternatives. We use G_MERGE_VALUES where possible, and a sequence of G_INSERTs if not. llvm-svn: 306119
* [GISel]: Add G_FMA opcode for fused multiply addsAditya Nandakumar2017-06-201-0/+12
| | | | | | | | https://reviews.llvm.org/D34372 Reviewed by dsanders llvm-svn: 305824
* [globalisel][tablegen] Add support for COPY_TO_REGCLASS.Daniel Sanders2017-06-201-2/+2
| | | | | | | | | | | | | | | | | | | | | | Summary: As part of this * Emitted instructions now have named MachineInstr variables associated with them. This isn't particularly important yet but it's a small step towards multiple-insn emission. * constrainSelectedInstRegOperands() is no longer hardcoded. It's now added as the ConstrainOperandsToDefinitionAction() action. COPY_TO_REGCLASS uses an alternate constraint mechanism ConstrainOperandToRegClassAction() which supports arbitrary constraints such as that defined by COPY_TO_REGCLASS. Reviewers: ab, qcolombet, t.p.northover, rovka, kristof.beyls, aditya_nandakumar Reviewed By: ab Subscribers: javed.absar, igorb, llvm-commits Differential Revision: https://reviews.llvm.org/D33590 llvm-svn: 305791
* [globalisel][legalizer] G_LOAD/G_STORE NarrowScalar should not emit G_GEP x, 0.Daniel Sanders2017-06-131-6/+2
| | | | | | | | | | | | | | | | | | | Summary: When legalizing G_LOAD/G_STORE using NarrowScalar, we should avoid emitting %0 = G_CONSTANT ty 0 %1 = G_GEP %x, %0 since it's cheaper to not emit the redundant instructions than it is to fold them away later. Reviewers: qcolombet, t.p.northover, ab, rovka, aditya_nandakumar, kristof.beyls Reviewed By: qcolombet Subscribers: javed.absar, llvm-commits, igorb Differential Revision: https://reviews.llvm.org/D32746 llvm-svn: 305340
* Vivek Pandya2017-06-0622-558/+561
| | | | | | | | | | | | [Improve CodeGen Testing] This patch renables MIRPrinter print fields which have value equal to its default. If -simplify-mir option is passed then MIRPrinter will not print such fields. This change also required some lit test cases in CodeGen directory to be changed. Reviewed By: MatzeB Differential Revision: https://reviews.llvm.org/D32304 llvm-svn: 304779
* [GlobalISel] IRTranslator: Add MachineMemOperand to target memory intrinsicsVolkan Keles2017-06-051-0/+12
| | | | | | | | | | | | Reviewers: qcolombet, ab, t.p.northover, aditya_nandakumar, dsanders Reviewed By: qcolombet Subscribers: rovka, kristof.beyls, javed.absar, igorb, llvm-commits Differential Revision: https://reviews.llvm.org/D33724 llvm-svn: 304743
* MIR: remove explicit "noVRegs" property.Tim Northover2017-05-301-1/+0
| | | | | | | We can infer this from the incoming MIR, so there's no reason to represent it with a special flag. llvm-svn: 304246
* [Localizer] Don't trick to be smart for the insertion pointQuentin Colombet2017-05-301-0/+49
| | | | | | | | | There is no guarantee that the first use of a constant that is traversed is actually the first in the related basic block. Thus, if we use that as the insertion point we may end up with definitions that don't dominate there use. llvm-svn: 304244
* [AArch64][GlobalISel] Add the Localizer pass for the O0 pipelineQuentin Colombet2017-05-273-3/+100
| | | | | | | This should fix most of the issue we have right now with constants being spilled all over the place. llvm-svn: 304052
* [GlobalISel] Add a localizer pass for target to useQuentin Colombet2017-05-271-0/+312
| | | | | | | | | | | | | This reverts commit r299287 plus clean-ups. The localizer pass is a helper pass that could be run at O0 in the GISel pipeline to work around the deficiency of the fast register allocator. It basically shortens the live-ranges of the constants so that the allocator does not spill all over the place. Long term fix would be to make the greedy allocator fast. llvm-svn: 304051
* [AArch64][RegisterBankInfo] Change the default mapping of fp stores.Quentin Colombet2017-05-101-0/+46
| | | | | | | | For stores, check if the stored value is defined by a floating point instruction and if yes, we return a default mapping with FPR instead of GPR. llvm-svn: 302679
* Add extra operand to CALLSEQ_START to keep frame part set up previouslySerge Pavlov2017-05-091-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Using arguments with attribute inalloca creates problems for verification of machine representation. This attribute instructs the backend that the argument is prepared in stack prior to CALLSEQ_START..CALLSEQ_END sequence (see http://llvm.org/docs/InAlloca.htm for details). Frame size stored in CALLSEQ_START in this case does not count the size of this argument. However CALLSEQ_END still keeps total frame size, as caller can be responsible for cleanup of entire frame. So CALLSEQ_START and CALLSEQ_END keep different frame size and the difference is treated by MachineVerifier as stack error. Currently there is no way to distinguish this case from actual errors. This patch adds additional argument to CALLSEQ_START and its target-specific counterparts to keep size of stack that is set up prior to the call frame sequence. This argument allows MachineVerifier to calculate actual frame size associated with frame setup instruction and correctly process the case of inalloca arguments. The changes made by the patch are: - Frame setup instructions get the second mandatory argument. It affects all targets that use frame pseudo instructions and touched many files although the changes are uniform. - Access to frame properties are implemented using special instructions rather than calls getOperand(N).getImm(). For X86 and ARM such replacement was made previously. - Changes that reflect appearance of additional argument of frame setup instruction. These involve proper instruction initialization and methods that access instruction arguments. - MachineVerifier retrieves frame size using method, which reports sum of frame parts initialized inside frame instruction pair and outside it. The patch implements approach proposed by Quentin Colombet in https://bugs.llvm.org/show_bug.cgi?id=27481#c1. It fixes 9 tests failed with machine verifier enabled and listed in PR27481. Differential Revision: https://reviews.llvm.org/D32394 llvm-svn: 302527
* [AArch64][RegisterBankInfo] Change the default mapping of fp loads.Quentin Colombet2017-05-081-0/+50
| | | | | | | | | | | This fixes PR32550, in a way that does not imply running the greedy mode at O0. The fix consists in checking if a load is used by any floating point instruction and if yes, we return a default mapping with FPR instead of GPR. llvm-svn: 302453
* [GISel]: Add support to translate ConstantVectorsAditya Nandakumar2017-05-041-0/+9
| | | | | | | Reviewed by Quentin https://reviews.llvm.org/D32814 llvm-svn: 302196
* Cleanup tests to not share a DISubprogram between multiple Functions.Adrian Prantl2017-05-042-20/+28
| | | | | | rdar://problem/31926379 llvm-svn: 302166
* [globalisel][tablegen] Fix PR32733 by checking which instruction operands ↵Daniel Sanders2017-04-221-0/+65
| | | | | | | | | | | | | belong to. canMutate() was returning true when the operands were all in the same order as the matched instruction. However, it wasn't checking the operands were actually on that instruction. This worked when we could only match a single instruction but the addition of nested instruction matching led to cases where the operands could be split across multiple instructions. canMutate() now returns false if operands belong to instructions other than the root of the match. llvm-svn: 301077
* [GlobalISel] Support vector-of-pointers in LLTKristof Beyls2017-04-191-0/+16
| | | | | | | | | | | | | | | | | | | | | | | | | | | | This fixes PR32471. As comment 10 on that bug report highlights (https://bugs.llvm.org//show_bug.cgi?id=32471#c10), there are quite a few different defendable design tradeoffs that could be made, including not representing pointers at all in LLT. I decided to go for representing vector-of-pointer as a concept in LLT, while keeping the size of the LLT type 64 bits (this is an increase from 48 bits before). My rationale for keeping pointers explicit is that on some targets probably it's very handy to have the distinction between pointer and non-pointer (e.g. 68K has a different register bank for pointers IIRC). If we keep a scalar pointer, it probably is easiest to also have a vector-of-pointers to keep LLT relatively conceptually clean and orthogonal, while we don't have a very strong reason to break that orthogonality. Once we gain more experience on the use of LLT, we can of course reconsider this direction. Rejecting vector-of-pointer types in the IRTranslator is also an option to avoid the crash reported in PR32471, but that is only a very short-term solution; also needs quite a bit of code tweaks in places, and is probably fragile. Therefore I didn't consider this the best option. llvm-svn: 300664
* Revert "[GlobalISel] Support vector-of-pointers in LLT"Kristof Beyls2017-04-181-16/+0
| | | | | | | | | | | | | | | | This reverts r300535 and r300537. The newly added tests in test/CodeGen/AArch64/GlobalISel/arm64-fallback.ll produces slightly different code between LLVM versions being built with different compilers. E.g., dependent on the compiler LLVM is built with, either one of the following can be produced: remark: <unknown>:0:0: unable to legalize instruction: %vreg0<def>(p0) = G_EXTRACT_VECTOR_ELT %vreg1, %vreg2; (in function: vector_of_pointers_extractelement) remark: <unknown>:0:0: unable to legalize instruction: %vreg2<def>(p0) = G_EXTRACT_VECTOR_ELT %vreg1, %vreg0; (in function: vector_of_pointers_extractelement) Non-determinism like this is clearly a bad thing, so reverting this until I can find and fix the root cause of the non-determinism. llvm-svn: 300538
* [GlobalISel] Support vector-of-pointers in LLTKristof Beyls2017-04-181-0/+16
| | | | | | | | | | | | | | | | | | | | | | | | | | | | This fixes PR32471. As comment 10 on that bug report highlights (https://bugs.llvm.org//show_bug.cgi?id=32471#c10), there are quite a few different defendable design tradeoffs that could be made, including not representing pointers at all in LLT. I decided to go for representing vector-of-pointer as a concept in LLT, while keeping the size of the LLT type 64 bits (this is an increase from 48 bits before). My rationale for keeping pointers explicit is that on some targets probably it's very handy to have the distinction between pointer and non-pointer (e.g. 68K has a different register bank for pointers IIRC). If we keep a scalar pointer, it probably is easiest to also have a vector-of-pointers to keep LLT relatively conceptually clean and orthogonal, while we don't have a very strong reason to break that orthogonality. Once we gain more experience on the use of LLT, we can of course reconsider this direction. Rejecting vector-of-pointer types in the IRTranslator is also an option to avoid the crash reported in PR32471, but that is only a very short-term solution; also needs quite a bit of code tweaks in places, and is probably fragile. Therefore I didn't consider this the best option. llvm-svn: 300535
* [GlobalISel] LegalizerInfo: Enable legalization of non-power-of-2 typesVolkan Keles2017-04-112-0/+37
| | | | | | | | | | | | | | Summary: Legalize only if the type is marked as Legal or Custom. If not, return Unsupported as LegalizerHelper is not able to handle non-power-of-2 types right now. Reviewers: qcolombet, aditya_nandakumar, dsanders, t.p.northover, kristof.beyls, javed.absar, ab Reviewed By: kristof.beyls, ab Subscribers: dberris, rovka, igorb, llvm-commits Differential Revision: https://reviews.llvm.org/D31711 llvm-svn: 299929
* Add address space mangling to lifetime intrinsicsMatt Arsenault2017-04-101-4/+4
| | | | | | In preparation for allowing allocas to have non-0 addrspace. llvm-svn: 299876
* [GlobalISel]: Fix bug where we can report GISelFailure on erased instructionsAditya Nandakumar2017-04-071-0/+8
| | | | | | | | | | | | | The original instruction might get legalized and erased and expanded into intermediate instructions and the intermediate instructions might fail legalization. This end up in reporting GISelFailure on the erased instruction. Instead report GISelFailure on the intermediate instruction which failed legalization. Reviewed by: ab llvm-svn: 299802
* [tablegen][globalisel] Add support for nested instruction matching.Daniel Sanders2017-04-042-26/+128
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: Lift the restrictions that prevented the tree walking introduced in the previous change and add support for patterns like: (G_ADD (G_MUL (G_SEXT $src1), (G_SEXT $src2)), $src3) -> SMADDWrrr $dst, $src1, $src2, $src3 Also adds support for G_SEXT and G_ZEXT to support these cases. One particular aspect of this that I should draw attention to is that I've tried to be overly conservative in determining the safety of matches that involve non-adjacent instructions and multiple basic blocks. This is intended to be used as a cheap initial check and we may add a more expensive check in the future. The current rules are: * Reject if any instruction may load/store (we'd need to check for intervening memory operations. * Reject if any instruction has implicit operands. * Reject if any instruction has unmodelled side-effects. See isObviouslySafeToFold(). Reviewers: t.p.northover, javed.absar, qcolombet, aditya_nandakumar, ab, rovka Reviewed By: ab Subscribers: igorb, dberris, llvm-commits, kristof.beyls Differential Revision: https://reviews.llvm.org/D30539 llvm-svn: 299430
* Revert "Localizer fun"Quentin Colombet2017-04-011-260/+0
| | | | | | | | This reverts commit r299283. Didn't intend to commit this :( llvm-svn: 299287
* [RegBankSelect] Support REG_SEQUENCE for generic mappingQuentin Colombet2017-04-011-0/+25
| | | | | | | | | | | | | | | | REG_SEQUENCE falls into the same category as COPY for operands mapping: - They don't have MCInstrDesc with register constraints - The input variable could use whatever register classes - It is possible to have register class already assigned to the operands In particular, given REG_SEQUENCE are always target specific because of the subreg indices. Those indices must apply to the register class of the definition of the REG_SEQUENCE and therefore, the target must set a register class to that definition. As a result, the generic code can always use that register class to derive a valid mapping for a REG_SEQUENCE. llvm-svn: 299285
* Localizer funQuentin Colombet2017-04-011-0/+260
| | | | | | WIP llvm-svn: 299283
* [GlobalISel][AArch64] Fold FI into LDR/STR ui addressing mode.Ahmed Bougacha2017-03-272-0/+66
| | | | | | | | A majority of loads and stores at O0 access an alloca. It's trivial to fold the G_FRAME_INDEX into the instruction; do it. llvm-svn: 298864
* [GlobalISel][AArch64] Fold G_GEP into LDR/STR ui addressing mode.Ahmed Bougacha2017-03-272-0/+468
| | | | | | | | | | We're not to the point of supporting the load/store patterns yet (because they extensively use PatFrags). But in the meantime, we can implement some of the simplest addressing modes. llvm-svn: 298863
* [GlobalISel][AArch64] Select store of zero to WZR/XZR.Ahmed Bougacha2017-03-271-0/+56
| | | | | | These occur very frequently, and are quite trivial to catch. llvm-svn: 298862
* [GlobalISel][AArch64] Select CBZ.Ahmed Bougacha2017-03-271-0/+108
| | | | | | | | | | CBZ/CBNZ represent a substantial portion of all conditional branches. Look through G_ICMP to select them. We can't use tablegen yet because the existing patterns match an AArch64ISD node. llvm-svn: 298856
* [GlobalISel][AArch64] Use proper constant types in test. NFC.Ahmed Bougacha2017-03-271-2/+2
| | | | llvm-svn: 298854
* [GlobalISel]: Create VREGs for ConstantInt argsAditya Nandakumar2017-03-221-1/+2
| | | | | | | | | | | | This patch changes the behavior of IRTranslating intrinsics where we now create VREG + G_CONSTANT for ConstantInt values. We already do this for FloatingPoint values. This makes it easier for the backends to select code and it won't have to de-duplicate creation+selection of constants. Reviewed by: ab llvm-svn: 298473
* [GlobalISel] Update DBG_VALUEs referencing DCE'd instructions.Ahmed Bougacha2017-03-211-7/+29
| | | | | | | | | | | | | Quentin points out that r298358 would cause us to emit different code with debug info. That's a big no-no; also erase the instructions that only live thanks to DBG_VALUE users. Adrian explained how this is an existing problem and an OK thing to do: clang has allocas for all variables so shouldn't be affected at -O0, but swift uses a bit of inlineasm to explicitly keep values live for the purpose of debug info quality. I'm not sure there is a better scheme. llvm-svn: 298460
* [GlobalISel] Don't translate br to layout successor.Ahmed Bougacha2017-03-211-8/+29
| | | | | | | | | | MI can represent fallthrough to layout successor blocks, and our post-isel representation uses that extensively. We might as well use it too, to avoid translating and carrying along unnecessary branches. llvm-svn: 298459
* GlobalISel: widen booleans by zero-extending to a byte.Tim Northover2017-03-211-1/+1
| | | | | | | A bool is represented by a single byte, which the ARM ABI requires to be either 0 or 1. So we cannot use G_ANYEXT when legalizing the type. llvm-svn: 298439
* [GlobalISel] Fix shufflevector testsVolkan Keles2017-03-211-17/+17
| | | | | | | | clang-lld-x86_64-2stage fails because of the order of the instructions. `CHECK-DAG` directives should fix the problem. llvm-svn: 298367
* [GlobalISel] Translate shufflevectorVolkan Keles2017-03-211-0/+108
| | | | | | | | | | | | Reviewers: qcolombet, aditya_nandakumar, t.p.northover, javed.absar, ab, dsanders Reviewed By: javed.absar Subscribers: dberris, rovka, llvm-commits, kristof.beyls Differential Revision: https://reviews.llvm.org/D30962 llvm-svn: 298347
* GlobalISel: add implicit defs & uses when mutating an instruction.Tim Northover2017-03-201-2/+2
| | | | | | Otherwise a scheduler might do bad things to the code we produce. llvm-svn: 298311
* GlobalISel: allow quad-precision values to be dumped.Tim Northover2017-03-201-0/+8
| | | | | | | Otherwise the fallback path fails with an assertion on AAPCS AArch64 targets, when "long double" is encountered. llvm-svn: 298273
* [GlobalISel] Use the correct calling conv for callsDiana Picus2017-03-201-0/+10
| | | | | | | | | | | This commit adds a parameter that lets us pass in the calling convention of the call to CallLowering::lowerCall. This allows us to handle situations where the calling convetion of the callee is different from that of the caller. Differential Revision: https://reviews.llvm.org/D31039 llvm-svn: 298254
* [GlobalISel] Don't select trivially dead instructions.Ahmed Bougacha2017-03-1910-14/+113
| | | | | | | | | | | | | | Folding instructions when selecting can cause them to become dead. Don't select these dead instructions (if they don't have other side effects, and don't define physical registers). Preserve existing tests by adding COPYs. In some tests, the G_CONSTANT vregs never get constrained to a class: the only use of the vreg was folded into another instruction, so the G_CONSTANT, now dead, never gets selected. llvm-svn: 298224
* [GlobalISel][AArch64] Add DBG_VALUE select test. NFC.Ahmed Bougacha2017-03-191-0/+47
| | | | llvm-svn: 298223
* [GlobalISel][AArch64] Split out cast select tests. NFC.Ahmed Bougacha2017-03-195-405/+437
| | | | | | | | | | | | And remove some redundant bitcast tests. Also split the test functions themselves: it makes it obvious to see what's tested where and what isn't, it makes the tests much easier to read and manually update, and, most importantly, it makes them almost trivial to update using tooling. Yes, it's obnoxiously verbose, but said tooling helps upgrade to better MIR syntax whenever available. llvm-svn: 298222
OpenPOWER on IntegriCloud