summaryrefslogtreecommitdiffstats
path: root/llvm/lib/Target/ARM/ARMRegisterBankInfo.cpp
Commit message (Collapse)AuthorAgeFilesLines
* [GlobalISel][ARM] Adding HPR and QPR regclasses to FPRB regbankRoman Tereshin2018-05-231-0/+5
| | | | | | | | | | | Also bringing ARMRegisterBankInfo::getRegBankFromRegClass implementation up to speed with the *.td-definition. Reviewed By: qcolombet Differential Revision: https://reviews.llvm.org/D43982 llvm-svn: 333056
* [ARM GlobalISel] Map G_SITOFP and G_UITOFPDiana Picus2018-01-301-0/+14
| | | | | | | Straightforward mapping (integer operand to GPR, floating point operand to FPR). llvm-svn: 323731
* [ARM GlobalISel] Map G_FPTOSI and G_FPTOUIDiana Picus2018-01-301-0/+14
| | | | | | | Straightforward mapping (integer operand goes to GPR, floating point operand goes to FPR). llvm-svn: 323727
* [ARM GlobalISel] Map G_FPEXT and G_FPTRUNC to FPRDiana Picus2018-01-171-0/+18
| | | | llvm-svn: 322657
* [ARM GlobalISel] Map G_FMA to FPRDiana Picus2018-01-121-0/+14
| | | | llvm-svn: 322367
* [ARM GlobalISel] Map G_FNEG to the FPR bankDiana Picus2018-01-101-1/+2
| | | | llvm-svn: 322169
* [ARM GlobalISel] Support G_INTTOPTR and G_PTRTOINT for s32Diana Picus2017-12-221-0/+2
| | | | | | | Mark conversions between pointers and 32-bit scalars as legal, map them to the GPR and select to a simple COPY. llvm-svn: 321356
* [ARM GlobalISel] Fix assertion in RegBankSelectDiana Picus2017-12-201-1/+17
| | | | | | | | | | | | | | | | | | | | We get an assertion in RegBankSelect for code along the lines of my_32_bit_int = my_64_bit_int, which tends to translate into a 64-bit load, followed by a G_TRUNC, followed by a 32-bit store. This appears in a couple of places in the test-suite. At the moment, the legalizer doesn't distinguish between integer and floating point scalars, so a 64-bit load will be marked as legal for targets with VFP, and so will the rest of the sequence, leading to a slightly bizarre G_TRUNC reaching RegBankSelect. Since the current support for 64-bit integers is rather immature, this patch works around the issue by explicitly handling this case in RegBankSelect and InstructionSelect. In the future, we may want to revisit this decision and make sure 64-bit integer loads are narrowed before reaching RegBankSelect. llvm-svn: 321165
* [ARM GlobalISel] Support G_FDIV for s32 and s64Diana Picus2017-11-231-1/+2
| | | | | | | | | | | | TableGen already generates code for selecting a G_FDIV, so we only need to add a test. For the legalizer and reg bank select, we do the same thing as for the other floating point binary operations: either mark as legal if we have a FP unit or lower to a libcall, and map to the floating point registers. llvm-svn: 318915
* [ARM GlobalISel] Support G_FMUL for s32 and s64Diana Picus2017-11-231-1/+2
| | | | | | | | | | | TableGen already generates code for selecting a G_FMUL, so we only need to add a test for that part. For the legalizer and reg bank select, we do the same thing as the other floating point binary operators: either mark as legal if we have a FP unit or lower to a libcall, and map to the floating point registers. llvm-svn: 318910
* Fix a bunch more layering of CodeGen headers that are in TargetDavid Blaikie2017-11-171-1/+1
| | | | | | | | All these headers already depend on CodeGen headers so moving them into CodeGen fixes the layering (since CodeGen depends on Target, not the other way around). llvm-svn: 318490
* [GlobalISel|ARM] : Allow legalizing G_FSUBJaved Absar2017-10-301-4/+3
| | | | | | | | Adding support for VSUB. Reviewed by: @rovka Differential Revision: https://reviews.llvm.org/D39261 llvm-svn: 316902
* [ARM] GlobalISel: Map shift operands to GPRsDiana Picus2017-10-061-0/+3
| | | | llvm-svn: 315067
* [GISEl]: Translate phi into G_PHIAditya Nandakumar2017-08-231-1/+1
| | | | | | | | | | G_PHI has the same semantics as PHI but also has types. This lets us verify that the types in the G_PHI are consistent. This also allows specifying legalization actions for G_PHIs. https://reviews.llvm.org/D36990 llvm-svn: 311596
* [GlobalISel] Make GlobalISel a non-optional library.Quentin Colombet2017-08-031-4/+0
| | | | | | | | With this change, the GlobalISel library gets always built. In particular, this is not possible to opt GlobalISel out of the build using the LLVM_BUILD_GLOBAL_ISEL variable any more. llvm-svn: 309990
* [ARM] GlobalISel: Map G_GLOBAL_VALUE to GPRDiana Picus2017-07-261-0/+1
| | | | | | A G_GLOBAL_VALUE is basically a pointer, so it should live in the GPR. llvm-svn: 309101
* [ARM] GlobalISel: Support G_BRCONDDiana Picus2017-07-141-0/+4
| | | | | | | | | | | | Insert a TSTri to set the flags and a Bcc to branch based on their values. This is a bit inefficient in the (common) cases where the condition for the branch comes from a compare right before the branch, since we set the flags both as part of the compare lowering and as part of the branch lowering. We're going to live with that until we settle on a principled way to handle this kind of situation, which occurs with other patterns as well (combines might be the way forward here). llvm-svn: 308009
* [ARM] GlobalISel: Support G_BRDiana Picus2017-07-131-0/+3
| | | | | | | | This boils down to not crashing in reg bank select due to the lack of register operands on this instruction, and adding some tests. The instruction selection is already covered by the TableGen'erated code. llvm-svn: 307904
* Fixup r307893: Silence warningDiana Picus2017-07-131-0/+2
| | | | | | | Silence unused variable warning in release builds. *sigh* llvm-svn: 307896
* [ARM] GlobalISel: Move local variable. NFCDiana Picus2017-07-131-4/+10
| | | | | | | Move a local variable from outside a switch to inside every case that needs it (which isn't all of the cases, of course). llvm-svn: 307893
* [ARM] GlobalISel: Add reg mapping for s64 G_FCMPDiana Picus2017-07-111-5/+9
| | | | | | Map the result into GPR and the operands into FPR. llvm-svn: 307653
* [ARM] GlobalISel: Map s32 G_FCMP in reg bank selectDiana Picus2017-07-061-0/+14
| | | | | | Map hard G_FCMP operands to FPR and the result to GPR. llvm-svn: 307245
* [ARM] GlobalISel: Support G_SELECT for i32Diana Picus2017-06-271-0/+12
| | | | | | | | | | * Mark as legal for (s32, i1, s32, s32) * Map everything into GPRs * Select to two instructions: a CMP of the condition against 0, to set the flags, and a MOVCCr to select between the two inputs based on the flags that we've just set llvm-svn: 306382
* [ARM] GlobalISel: Support G_ICMP for i32 and pointersDiana Picus2017-06-191-0/+10
| | | | | | | | | | | | | | Add support throughout the pipeline: - mark as legal for s32 and pointers - map to GPRs - lower to a sequence of instructions, which moves 0 or 1 into the result register based on the flags set by a CMPrr We have copied from FastISel a helper function which maps CmpInst predicates into ARMCC codes. Ideally, we should be able to move it somewhere that both FastISel and GlobalISel can use. llvm-svn: 305672
* [ARM] GlobalISel: Purge G_SEQUENCEDiana Picus2017-06-071-14/+16
| | | | | | | | | | | | | | | | | According to the commit message from r296921, G_MERGE_VALUES and G_INSERT are to be preferred over G_SEQUENCE. Therefore, stop generating G_SEQUENCE in the ARM backend and remove the code dealing with it. This boils down to the code breaking up double values for the soft float calling convention. Use G_MERGE_VALUES + G_UNMERGE_VALUES instead of G_SEQUENCE + G_EXTRACT for it. This maps very nicely to VMOVDRR + VMOVRRD and simplifies the code in the instruction selector. There's one occurence of G_SEQUENCE left in arm-irtranslator.ll, but that is part of the target-independent code for translating constant structs. Therefore, it is beyond the scope of this commit. llvm-svn: 304902
* [ARM] GlobalISel: Support G_XORDiana Picus2017-06-071-0/+1
| | | | | | | | | Same as the other binary operators: - legalize to 32 bits - map to GPRs - select to EORrr via TableGen'erated code llvm-svn: 304898
* [ARM] GlobalISel: Support G_ORDiana Picus2017-06-071-0/+1
| | | | | | | | | Same as the other binary operators: - legalize to 32 bits - map to GPRs - select ORRrr thanks to TableGen'erated code llvm-svn: 304890
* [ARM] GlobalISel: Support G_ANDDiana Picus2017-06-071-0/+1
| | | | | | | | | This is identical to the support for the other binary operators: - widen to s32 - map into GPR - select ANDrr (via TableGen'erated code) llvm-svn: 304885
* [ARM][GlobalISel] Support for G_ANYEXTDiana Picus2017-05-111-0/+1
| | | | | | | | | | | | | | G_ANYEXT can be introduced by the legalizer when widening scalars. Add support for it in the register bank info (same mapping as everything else) and in the instruction selector. When selecting it, we treat it as a COPY, just like G_TRUNC. On this occasion we get rid of some assertions in selectCopy so we can reuse it. This shouldn't be a problem at the moment since we're not supporting any complicated cases (e.g. FPR, different register banks). We might want to separate the paths when we do. llvm-svn: 302778
* [RegisterBankInfo] Uniquely allocate instruction mapping.Quentin Colombet2017-05-051-7/+7
| | | | | | | | | | This is a step toward having statically allocated instruciton mapping. We are going to tablegen them eventually, so let us reflect that in the API. NFC. llvm-svn: 302316
* [ARM] GlobalISel: Support G_(S|U)DIV for s32Diana Picus2017-04-241-0/+2
| | | | | | | | | Add support for both targets with hardware division and without. For hardware division we have to add support throughout the pipeline (legalizer, reg bank select, instruction select). For targets without hardware division, we only need to mark it as a libcall. llvm-svn: 301164
* [ARM] GlobalISel: Add support for G_TRUNCDiana Picus2017-04-211-0/+1
| | | | | | | | Select them as copies. We only select if both the source and the destination are on the same register bank, so this shouldn't cause any trouble. llvm-svn: 300971
* [ARM] GlobalISel: Add support for G_MULDiana Picus2017-04-191-0/+1
| | | | | | | | Support G_MUL, very similar to G_ADD and G_SUB. The only difference is in the instruction selector, where we have to select either MUL or MULv5 depending on the target. llvm-svn: 300665
* [ARM] GlobalISel: Add support for G_SUBDiana Picus2017-04-181-0/+1
| | | | | | | Support G_SUB throughout the GlobalISel pipeline. It is exactly the same as G_ADD, nothing fancy. llvm-svn: 300546
* [ARM] GlobalISel: Support SP in regbankselectDiana Picus2017-03-131-0/+1
| | | | | | | We used to hit an unreachable in getRegBankFromRegClass when dealing with the stack pointer. This commit adds support for the GPRsp reg class. llvm-svn: 297621
* GlobalISel: restrict G_EXTRACT instruction to just one operand.Tim Northover2017-03-061-4/+2
| | | | | | | A bit more painful than G_INSERT because it was more widely used, but this should simplify the handling of extract operations in most locations. llvm-svn: 297100
* [ARM] GlobalISel: Add mapping for G_CONSTANTDiana Picus2017-02-281-0/+1
| | | | | | | Like G_FRAME_INDEX, G_CONSTANT has one register operand and one non-register operand. llvm-svn: 296469
* [ARM] GlobalISel: Add reg bank mapping for G_GEPDiana Picus2017-02-281-0/+1
| | | | | | This should be the same as the mapping for G_ADD etc. llvm-svn: 296455
* [ARM] GlobalISel: Add reg bank mappings for storesDiana Picus2017-02-241-0/+2
| | | | | | Same as the ones for loads. llvm-svn: 296115
* [ARM] GlobalISel: Check mappings used by reg bank selectDiana Picus2017-02-171-21/+120
| | | | | | | | Add some asserts to make sure we're using the mappings that we think we're using. This is to keep us from accidentally breaking functionality while moving to TableGen'erated mappings. llvm-svn: 295441
* [ARM] GlobalISel: Assert that we don't use the FPR bank if we don't have VFPDiana Picus2017-02-161-0/+12
| | | | llvm-svn: 295308
* [ARM] GlobalISel: Add reg bank mappings for G_SEQUENCE and G_EXTRACTDiana Picus2017-02-161-0/+26
| | | | | | | Support G_SEQUENCE and G_EXTRACT as needed for passing double precision floating point values in the soft-fp float mode. llvm-svn: 295306
* [ARM] GlobalISel: Make the FPR bank 64-bit wideDiana Picus2017-02-161-4/+21
| | | | | | | Also add mappings for single and double precision FP, and use them for G_FADD and G_LOAD. llvm-svn: 295302
* [ARM] GlobalISel: Add FPR reg bankDiana Picus2017-02-081-1/+9
| | | | | | | | | | | | | Add a register bank for floating point values and select simple instructions using them (add, copies from GPR). This assumes that the hardware can cope with a single precision add (VADDS) instruction, so the legalizer will treat G_FADD as legal and the instruction selector will refuse to select if the hardware doesn't support it. In the future we'll want to be more careful about this, and legalize to libcalls if we have to use soft float. llvm-svn: 294442
* [globalisel][arm] Tablegen-erate current Register Bank Information.Daniel Sanders2017-02-051-32/+4
| | | | | | | | | | | | | | | | | | Summary: This patch tablegen-erates the ARM register bank information so that the static tables added in D27807 no longer need to be maintained. Depends on D27338 Reviewers: t.p.northover, rovka, ab, qcolombet, aditya_nandakumar Reviewed By: rovka Subscribers: aemerson, rengolin, mgorny, dberris, kristof.beyls, llvm-commits Differential Revision: https://reviews.llvm.org/D28567 llvm-svn: 294124
* [ARM] GlobalISel: Support i8/i16 ABI extensionsDiana Picus2017-01-251-0/+3
| | | | | | | | | | | | | At the moment, this means supporting the signext/zeroext attribute on the return type of the function. For function arguments, signext/zeroext should be handled by the caller, so there's nothing for us to do until we start lowering calls. Note that this does not include support for other extensions (i8 to i16), those will be added later. Differential Revision: https://reviews.llvm.org/D27705 llvm-svn: 293034
* Re-commit: [globalisel] Tablegen-erate current Register Bank InformationDaniel Sanders2017-01-191-1/+3
| | | | | | | | | | | | | | | | | | | | | Summary: Adds a RegisterBank tablegen class that can be used to declare the register banks and an associated tablegen pass to generate the necessary code. Changes since first commit attempt: * Added missing guards * Added more missing guards * Found and fixed a use-after-free bug involving Twine locals Reviewers: t.p.northover, ab, rovka, qcolombet Reviewed By: qcolombet Subscribers: aditya_nandakumar, rengolin, kristof.beyls, vkalintiris, mgorny, dberris, llvm-commits, rovka Differential Revision: https://reviews.llvm.org/D27338 llvm-svn: 292478
* Re-revert: [globalisel] Tablegen-erate current Register Bank InformationDaniel Sanders2017-01-181-3/+1
| | | | | | | More missing guards. My build didn't notice it due to a stale file left over from a Global ISel build. llvm-svn: 292369
* Re-commit: [globalisel] Tablegen-erate current Register Bank InformationDaniel Sanders2017-01-181-1/+3
| | | | | | | | | | | | | | | | | | | | | | | Summary: Adds a RegisterBank tablegen class that can be used to declare the register banks and an associated tablegen pass to generate the necessary code. Changes since last commit: The new tablegen pass is now correctly guarded by LLVM_BUILD_GLOBAL_ISEL and this should fix the buildbots however it may not be the whole fix. The previous buildbot failures suggest there may be a memory bug lurking that I'm unable to reproduce (including when using asan) or spot in the source. If they re-occur on this commit then I'll need assistance from the bot owners to track it down. Reviewers: t.p.northover, ab, rovka, qcolombet Reviewed By: qcolombet Subscribers: aditya_nandakumar, rengolin, kristof.beyls, vkalintiris, mgorny, dberris, llvm-commits, rovka Differential Revision: https://reviews.llvm.org/D27338 llvm-svn: 292367
* Revert r292132: [globalisel] Tablegen-erate current Register Bank ↵Daniel Sanders2017-01-161-3/+1
| | | | | | | | | Information'... Several buildbots encountered a crash in tablegen when building this commit. Reverting while I investigate the cause. llvm-svn: 292136
OpenPOWER on IntegriCloud