summaryrefslogtreecommitdiffstats
path: root/llvm/lib/Target/ARM/ARMRegisterBankInfo.cpp
Commit message (Collapse)AuthorAgeFilesLines
* 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
* [globalisel] Tablegen-erate current Register Bank InformationDaniel Sanders2017-01-161-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. Reviewers: t.p.northover, ab, rovka, qcolombet Subscribers: aditya_nandakumar, rengolin, kristof.beyls, vkalintiris, mgorny, dberris, llvm-commits, rovka Differential Revision: https://reviews.llvm.org/D27338 llvm-svn: 292132
* [globalisel] Move as much RegisterBank initialization to the constructor as ↵Daniel Sanders2017-01-121-3/+3
| | | | | | | | | | | | | | | | | | | | | possible Summary: The register bank is now entirely initialized in the constructor. However, we still have the hardcoded number of register classes which will be dealt with in the TableGen patch (D27338) since we do not have access to this information to resolve this at this stage. The number of register classes is known to the TRI and to TableGen but the RegisterBank constructor is too early for the former and too late for the latter. This will be fixed when the data is tablegen-erated. Reviewers: t.p.northover, ab, rovka, qcolombet Subscribers: aditya_nandakumar, kristof.beyls, vkalintiris, llvm-commits, dberris Differential Revision: https://reviews.llvm.org/D27809 llvm-svn: 291770
* [globalisel] Initialize RegisterBanks with static data.Daniel Sanders2017-01-121-4/+27
| | | | | | | | | | | | | | | | | | | | | | | | Summary: Refactor the RegisterBank initialization to use static data. This requires GlobalISel implementations to rewrite calls to createRegisterBank() and addRegBankCoverage() into a call to setRegBankData(). Out of tree targets can use diff 4 of D27807 (https://reviews.llvm.org/D27807?id=84117) to have addRegBankCoverage() dump the register classes and other data that needs to be provided to setRegBankData(). This is the method that was used to generate the static data in this patch. Tablegen-eration of this static data will follow after some refactoring. Reviewers: t.p.northover, ab, rovka, qcolombet Subscribers: aditya_nandakumar, kristof.beyls, vkalintiris, llvm-commits, dberris Differential Revision: https://reviews.llvm.org/D27807 Differential Revision: https://reviews.llvm.org/D27808 llvm-svn: 291768
* [ARM] GlobalISel: Support loading from the stackDiana Picus2016-12-191-6/+19
| | | | | | | | | | Add support for selecting simple G_LOAD and G_FRAME_INDEX instructions (32-bit scalars only). This will be useful for functions that need to pass arguments on the stack. First part of https://reviews.llvm.org/D27195. llvm-svn: 290096
* [ARM] GlobalISel: Select add i32, i32Diana Picus2016-12-161-1/+88
| | | | | | | | | | | | | Add the minimal support necessary to select a function that returns the sum of two i32 values. This includes some support for argument/return lowering of i32 values through registers, as well as the handling of copy and add instructions throughout the GlobalISel pipeline. Differential Revision: https://reviews.llvm.org/D26677 llvm-svn: 289940
* [ARM] Add plumbing for GlobalISelDiana Picus2016-11-111-0/+27
Add GlobalISel skeleton, up to the point where we can select a ret void. llvm-svn: 286573
OpenPOWER on IntegriCloud