summaryrefslogtreecommitdiffstats
path: root/llvm/lib/Target/AArch64/AArch64RegisterBankInfo.h
Commit message (Collapse)AuthorAgeFilesLines
* GlobalISel: Add type argument to getRegBankFromRegClassMatt Arsenault2020-01-031-2/+2
| | | | | | AMDGPU can't unambiguously go back from the selected instruction register class to the register bank without knowing if this was used in a boolean context.
* [AArch64][GlobalISel] Overhaul legalization & isel or shifts to select ↵Amara Emerson2019-07-031-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | immediate forms. There are two main issues preventing us from generating immediate form shifts: 1) We have partial SelectionDAG imported support for G_ASHR and G_LSHR shift immediate forms, but they currently don't work because the amount type is expected to be an s64 constant, but we only legalize them to have homogenous types. To deal with this, first we introduce a custom legalizer to *only* custom legalize s32 shifts which have a constant operand into a s64. There is also an additional artifact combiner to fold zexts(g_constant) to a larger G_CONSTANT if it's legal, a counterpart to the anyext version committed in an earlier patch. 2) For G_SHL the importer can't cope with the pattern. For this I introduced an early selection phase in the arm64 selector to select these forms manually before the tablegen selector pessimizes it to a register-register variant. Differential Revision: https://reviews.llvm.org/D63910 llvm-svn: 364994
* [GlobalISel][AArch64] Make FP constraint checks consider possible use/def banksJessica Paquette2019-05-241-0/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | In a few places in getInstrMapping, we check if use/def instructions for the instruction we're mapping have floating point constraints. We can improve this check and reduce the number of copies in GISel-compiled code if we make a couple observations: - For a def instruction, it only matters if the def instruction must always output a value stored on a FPR - For a use instruction, it only matters if the use instruction must always only take in values stored in FPRs This adds two new functions: - onlyUsesFP - onlyDefinesFP Then we can use those when we're checking the uses/defs instead. Without this patch, the load, unmerge, store, and select in the added test would have unnecessary copies. Differential Revision: https://reviews.llvm.org/D62426 llvm-svn: 361679
* [GlobalISel][AArch64] NFC: Factor out HasFPConstraints into a proper functionJessica Paquette2019-05-241-0/+4
| | | | | | | | | Factor it out into a function, and replace places where we had the same check with the new function. Differential Revision: https://reviews.llvm.org/D62421 llvm-svn: 361677
* Update the file headers across all of the LLVM projects in the monorepoChandler Carruth2019-01-191-4/+3
| | | | | | | | | | | | | | | | | to reflect the new license. We understand that people may be surprised that we're moving the header entirely to discuss the new license. We checked this carefully with the Foundation's lawyer and we believe this is the correct approach. Essentially, all code in the project is now made available by the LLVM project under our new license, so you will see that the license headers include that license only. Some of our contributors have contributed code under our old license, and accordingly, we have retained a copy of our old license notice in the top-level files in each project and repository. llvm-svn: 351636
* [AArch64][RegisterBankInfo] Add mapping for G_FPEXT.Quentin Colombet2017-11-021-1/+14
| | | | | | | | | | This fixes http://llvm.org/PR32560. We were missing a description for half floating point type and as a result were using the FPR 32 mapping. Because of the size mismatch the generic code was complaining that the default mapping is not appropriate. Fix the mapping description so that the default mapping can be properly applied. llvm-svn: 317287
* [AArch64][RegisterBankInfo] Add FPR16 support in value mapping.Quentin Colombet2017-11-021-6/+6
| | | | | | NFC. llvm-svn: 317286
* [RegisterBankInfo] Uniquely allocate instruction mapping.Quentin Colombet2017-05-051-3/+4
| | | | | | | | | | 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
* GlobalISel: fall back gracefully when we can't map an operand's size.Tim Northover2017-02-061-4/+5
| | | | | | | | AArch64 was asserting when it was asked to provide a register-bank of a size it couldn't deal with (in this case an s128 IMPLICIT_DEF). But we want a robust fallback path so this isn't allowed. llvm-svn: 294248
* Re-commit: [globalisel] Tablegen-erate current Register Bank InformationDaniel Sanders2017-01-191-18/+11
| | | | | | | | | | | | | | | | | | | | | 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-11/+18
| | | | | | | 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-18/+11
| | | | | | | | | | | | | | | | | | | | | | | 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-11/+18
| | | | | | | | | 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-18/+11
| | | | | | | | | | | | | | 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][aarch64] Make getCopyMapping() take register banks ID's rather ↵Daniel Sanders2017-01-131-13/+11
| | | | | | | | | | | | | | | | | than IsGPR booleans Summary: This allows the function to handle architectures with more than two register banks. Depends on D27978 Reviewers: ab, t.p.northover, rovka, qcolombet Subscribers: aditya_nandakumar, kristof.beyls, aemerson, rengolin, vkalintiris, dberris, llvm-commits, rovka Differential Revision: https://reviews.llvm.org/D27339 llvm-svn: 291902
* [aarch64][globalisel] Move getValueMapping/getCopyMapping to ↵Daniel Sanders2017-01-131-45/+22
| | | | | | | | | | | | | | | | | | | | | AArch64GenRegisterBankInfo. NFC. Summary: We did lose a little specificity in the assertion messages for the PartialMappingIdx enumerators in this change but this was necessary to avoid unnecessary use of 'public:' and we haven't lost anything that can't be discovered easily in lldb. Once this is tablegen-erated we could also safely remove the assertions. Depends on D27976 Reviewers: t.p.northover, ab, rovka, qcolombet Subscribers: aditya_nandakumar, aemerson, rengolin, vkalintiris, dberris, kristof.beyls, llvm-commits Differential Revision: https://reviews.llvm.org/D27978 llvm-svn: 291900
* [aarch64][globalisel] Refactor getRegBankBaseIdxOffset() to remove the ↵Daniel Sanders2017-01-131-0/+23
| | | | | | | | | | | | | | | | | power-of-2 assumption. NFC Summary: We don't exploit it yet though Depends on D27976 Reviewers: t.p.northover, ab, rovka, qcolombet Subscribers: aditya_nandakumar, aemerson, rengolin, vkalintiris, dberris, kristof.beyls, llvm-commits Differential Revision: https://reviews.llvm.org/D27977 llvm-svn: 291899
* [aarch64][globalisel] Move data into <Target>GenRegisterBankInfo. NFC.Daniel Sanders2017-01-131-5/+66
| | | | | | | | | | | | Summary: Depends on D27809 Reviewers: t.p.northover, rovka, qcolombet, ab Subscribers: aditya_nandakumar, aemerson, rengolin, vkalintiris, dberris, kristof.beyls, llvm-commits Differential Revision: https://reviews.llvm.org/D27976 llvm-svn: 291897
* [AArch64][GlobalISel] Remove redundant RBI comments. NFC.Ahmed Bougacha2016-12-151-20/+1
| | | | | | | It's brittle, and Doxygen already picks the overriden method's comment anyway. llvm-svn: 289844
* [AArch64][RegisterBankInfo] Add getSameKindofOperandsMapping.Quentin Colombet2016-10-031-0/+10
| | | | | | | | | | Refactor the code so that the same function can be used for all instructions with all the same operands for up to 3 operands. This is going to be useful for cast instructions. NFC. llvm-svn: 283144
* [RegisterBankInfo] Move to statically allocated RegisterBank.Quentin Colombet2016-09-221-0/+4
| | | | | | | | | | | | This commit is basically the first step toward what will RegisterBankInfo look when it gets TableGen'ed. It introduces a XXXGenRegisterBankInfo.def file that is what TableGen will issue at some point. Moreover, the RegBanks field in RegisterBankInfo changed to reflect the static (compile time) aspect of the information. llvm-svn: 282131
* [AArch64] Mark various *Info classes as 'final'. NFC.Ahmed Bougacha2016-07-271-1/+1
| | | | llvm-svn: 276874
* GlobalISel: implement low-level type with just size & vector lanes.Tim Northover2016-07-201-0/+2
| | | | | | | | This should be all the low-level instruction selection needs to determine how to implement an operation, with the remaining context taken from the opcode (e.g. G_ADD vs G_FADD) or other flags not based on type (e.g. fast-math). llvm-svn: 276158
* [AArch64][RegisterBankInfo] G_OR are fine on either GPR or FPR.Quentin Colombet2016-06-081-0/+8
| | | | | | | | | | Teach AArch64RegisterBankInfo that G_OR can be mapped on either GPR or FPR for 64-bit or 32-bit values. Add test cases demonstrating how this information is used to coalesce a computation on a single register bank. llvm-svn: 272170
* [RegisterBankInfo] Add a size argument for the cost of copy.Quentin Colombet2016-06-081-3/+7
| | | | | | | The cost of a copy may be different based on how many bits we have to copy around. E.g., a 8-bit copy may be different than a 32-bit copy. llvm-svn: 272084
* [AArch64] Teach RegisterBankInfo about the CC register bank.Quentin Colombet2016-04-071-0/+1
| | | | | | We need to cover each register class with a register bank. llvm-svn: 265629
* [AArch64] Teach RegisterBankInfo about the mapping of register classesQuentin Colombet2016-04-071-0/+15
| | | | | | on register banks. llvm-svn: 265626
* [AArch64] Initial implementation of the targeting of the register bank ↵Quentin Colombet2016-04-051-0/+41
information. llvm-svn: 265489
OpenPOWER on IntegriCloud