summaryrefslogtreecommitdiffstats
path: root/llvm/lib/Target/AArch64/AArch64RegisterBankInfo.cpp
Commit message (Collapse)AuthorAgeFilesLines
...
* GlobalISel: map 128-bit values to an FPR by default.Tim Northover2017-07-281-1/+2
| | | | | | | Eventually we may want to allow a pair of GPRs but absolutely nothing in the entire world is ready for that yet. llvm-svn: 309404
* GlobalISel: remove G_SEQUENCE instruction.Tim Northover2017-06-231-4/+0
| | | | | | | | 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
* Sort the remaining #include lines in include/... and lib/....Chandler Carruth2017-06-061-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | I did this a long time ago with a janky python script, but now clang-format has built-in support for this. I fed clang-format every line with a #include and let it re-sort things according to the precise LLVM rules for include ordering baked into clang-format these days. I've reverted a number of files where the results of sorting includes isn't healthy. Either places where we have legacy code relying on particular include ordering (where possible, I'll fix these separately) or where we have particular formatting around #include lines that I didn't want to disturb in this patch. This patch is *entirely* mechanical. If you get merge conflicts or anything, just ignore the changes in this patch and run clang-format over your #include lines in the files. Sorry for any noise here, but it is important to keep these things stable. I was seeing an increasing number of patches with irrelevant re-ordering of #include lines because clang-format was used. This patch at least isolates that churn, makes it easy to skip when resolving conflicts, and gets us to a clean baseline (again). llvm-svn: 304787
* [AArch64][RegisterBankInfo] Change the default mapping of fp stores.Quentin Colombet2017-05-101-0/+11
| | | | | | | | 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
* [AArch64][RegisterBankInfo] Change the default mapping of fp loads.Quentin Colombet2017-05-081-0/+14
| | | | | | | | | | | 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
* [AArch64][RegisterBankInfo] Fix mapping cost for GPR.Quentin Colombet2017-05-081-1/+1
| | | | | | | | | | | | | | | | In r292478, we changed the order of the enum that is referenced by PMI_FirstXXX. This had the side effect of changing the cost of the mapping of all the loads, instead of just the FPRs ones. Reinstate the higher cost for all but GPR loads. Note: This did not have any external visible effects: - For Fast mode, the cost would have been higher, but we don't care because we don't try to use alternative mappings. - For Greedy mode, the higher cost of the GPR loads, would have triggered the use of the supposedly alternative mapping, that would be in fact the same GPR mapping but with a lower cost. llvm-svn: 302452
* [RegisterBankInfo] Uniquely allocate instruction mapping.Quentin Colombet2017-05-051-30/+30
| | | | | | | | | | 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] Support vector-of-pointers in LLTKristof Beyls2017-04-191-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | 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-2/+2
| | | | | | | | | | | | | | | | 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-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | 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: fall back gracefully when we can't map an operand's size.Tim Northover2017-02-061-3/+9
| | | | | | | | 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
* [AArch64] Fix some Clang-tidy modernize and Include What You Use warnings; ↵Eugene Zelenko2017-02-011-18/+21
| | | | | | other minor fixes (NFC). llvm-svn: 293836
* Re-commit: [globalisel] Tablegen-erate current Register Bank InformationDaniel Sanders2017-01-191-3/+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/+3
| | | | | | | 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-3/+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/+3
| | | | | | | | | 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-3/+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][aarch64] Make getCopyMapping() take register banks ID's rather ↵Daniel Sanders2017-01-131-10/+10
| | | | | | | | | | | | | | | | | 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-17/+16
| | | | | | | | | | | | | | | | | | | | | 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-5/+7
| | | | | | | | | | | | | | | | | 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-82/+51
| | | | | | | | | | | | 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
* [globalisel] Move as much RegisterBank initialization to the constructor as ↵Daniel Sanders2017-01-121-15/+14
| | | | | | | | | | | | | | | | | | | | | 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-8/+4
| | | | | | | | | | | | | | | | | | | | | | | | 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
* GlobalISel: handle G_SEQUENCE fallbacks gracefully.Tim Northover2016-12-061-0/+4
| | | | | | | | | | There were two problems: + AArch64 was reusing random data from its binary op tables, which is complete nonsense for G_SEQUENCE. + Even when AArch64 gave up and said it couldn't handle G_SEQUENCE, the generic code asserted. llvm-svn: 288836
* [globalisel][aarch64] Fix unintended assumptions about PartialMappingIdx. NFC.Daniel Sanders2016-12-061-12/+14
| | | | | | | | | | | | | | | | | | | | | | Summary: This is NFC but prevents assertions when PartialMappingIdx is tablegen-erated. The assumptions were: 1) FirstGPR is 0 2) FirstGPR is the first of the First* enumerators. GPR32 is changed to 1 to demonstrate that assumption #1 is fixed. #2 will be covered by a subsequent patch that tablegen-erates information and swaps the order of GPR and FPR as a side effect. Depends on D27336 Reviewers: ab, t.p.northover, qcolombet Subscribers: aemerson, rengolin, vkalintiris, dberris, rovka, llvm-commits Differential Revision: https://reviews.llvm.org/D27337 llvm-svn: 288812
* [globalisel][aarch64] Correct argument names in comments.Daniel Sanders2016-12-061-3/+3
| | | | llvm-svn: 288809
* [globalisel][aarch64] Prefix PartialMappingIdx enumerators with 'PMI_' to ↵Daniel Sanders2016-12-061-50/+54
| | | | | | | | fit coding standards. This also stops things like 'None' polluting the llvm::AArch64 namespace. llvm-svn: 288799
* [AArch64][RegisterBankInfo] Fix typo in the logic used in assert.Quentin Colombet2016-12-051-1/+1
| | | | | | | Thanks to David Binderman <dcb314@hotmail.com> for bringing it to my attention. llvm-svn: 288688
* [AArch64][RegisterBankInfo] Switch to fully static opds mapping for G_BITCAST.Quentin Colombet2016-10-131-4/+10
| | | | | | NFC. llvm-svn: 284146
* [AArch64][RegisterBankInfo] Provide alternative mappings for 64-bit loadQuentin Colombet2016-10-131-1/+30
| | | | | | | | This allows RegBankSelect in greedy mode to get rid some of the cross register bank copies when loads are involved in the chain of computation. llvm-svn: 284097
* [AArch64][RegisterBankInfo] Provide alternative mappings for G_BITCASTs.Quentin Colombet2016-10-131-8/+45
| | | | | | | Thanks to this patch, RegBankSelect is able to get rid of some register bank copies as demonstrated in the test case. llvm-svn: 284094
* [AArch64][RegisterBankInfo] Describe cross regbank copies statically.Quentin Colombet2016-10-131-0/+30
| | | | | | NFC. llvm-svn: 284091
* [AArch64][RegisterBankInfo] Use static mapping for same bank G_BITCAST.Quentin Colombet2016-10-131-0/+8
| | | | | | NFC. llvm-svn: 284090
* [AArch64][RegisterBankInfo] Bump the cost of vector loads.Quentin Colombet2016-10-131-0/+10
| | | | | | | This does not change anything yet, because we do not offer any alternative mapping. llvm-svn: 284088
* [AArch64][RegisterBankInfo] Use a proper cost for cross regbank G_BITCASTs.Quentin Colombet2016-10-131-2/+11
| | | | | | | This does not change anything yet, because we do not offer any alternative mapping. llvm-svn: 284087
* [AArch64][RegisterBankInfo] Provide more realistic copy costs.Quentin Colombet2016-10-131-1/+10
| | | | llvm-svn: 284086
* [AArch64][RegisterBankInfo] Add getSameKindofOperandsMapping.Quentin Colombet2016-10-031-26/+44
| | | | | | | | | | 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
* [AArch64][RegisterBankInfo] Use the helper functions for the checksQuentin Colombet2016-09-301-29/+26
| | | | | | | | This makes sure the helper functions work as expected. NFC. llvm-svn: 282961
* [AArch64][RegisterBankInfo] Rename getValueMappingIdx to getValueMappingQuentin Colombet2016-09-301-8/+10
| | | | | | | | We don't return index, we return the actual ValueMapping. NFC. llvm-svn: 282960
* [AArch64][RegisterBankInfo] Compress the ValueMapping table a bit.Quentin Colombet2016-09-301-21/+15
| | | | | | | | | | We don't need to have singleton ValueMapping on their own, we can just reuse one of the elements of the 3-ops mapping. This allows even more code sharing. NFC. llvm-svn: 282959
* [AArch64][RegisterBankInfo] Refactor the code to access AArch64::ValMappingQuentin Colombet2016-09-301-23/+13
| | | | | | | | | Use a helper function to access ValMapping. This should make the code easier to understand and maintain. NFC. llvm-svn: 282958
* [AArch64][RegisterBankInfo] Rename getRegBankIdx to getRegBankIdxOffsetQuentin Colombet2016-09-301-16/+21
| | | | | | | | | The function name did not make it clear that the returned value was an offset to apply to a register bank index. NFC. llvm-svn: 282957
* [AArch64][RegisterBankInfo] Use the static opds mapping for alt mappingsQuentin Colombet2016-09-301-14/+7
| | | | | | | | Avoid to rely on the dynamically allocated operands mapping for the alternative mapping. NFC. llvm-svn: 282956
* [AArch64][RegisterBankInfo] Use static mapping for 3-operands instrs.Quentin Colombet2016-09-301-0/+50
| | | | | | | | This uses a TableGen'ed like structure for all 3-operands instrs. The output of the RegBankSelect pass should be identical but the RegisterBankInfo will do less dynamic allocations. llvm-svn: 282817
* [AArch64][RegisterBankInfo] Add static value mapping for 3-op instrs.Quentin Colombet2016-09-301-11/+36
| | | | | | | This is the kind of input TableGen should generate at some point. NFC. llvm-svn: 282816
* [AArch64][RegisterBankInfo] Check the statically created ValueMapping.Quentin Colombet2016-09-301-0/+18
| | | | | | | | | Make sure that the ValueMappings contain the value we expect at the indices we expect. NFC. llvm-svn: 282815
* [RegisterBankInfo] Uniquely generate OperandsMapping.Quentin Colombet2016-09-281-16/+27
| | | | | | | | | | | This is a step toward statically allocate InstructionMapping. Like the previous few commits, the goal is to move toward a TableGen'ed like structure with no dynamic allocation at all. This should already improve compile time by getting rid of a bunch of memmove of SmallVectors. llvm-svn: 282643
* [AArch64][RegisterBankInfo] Switch to statically allocated ValueMapping.Quentin Colombet2016-09-271-10/+5
| | | | | | | | Another step toward TableGen'ed like structure for the RegisterBankInfo of AArch64. By doing this, we also save a bit of compile time for the exact same output. llvm-svn: 282550
* [RegisterBankInfo] Uniquely generate ValueMapping.Quentin Colombet2016-09-241-9/+9
| | | | | | | | This is a step toward statically allocate ValueMapping. Like the previous few commits, the goal is to move toward a TableGen'ed like structure with no dynamic allocation at all. llvm-svn: 282324
* [AArch64][RegisterBankInfo] Sanity check TableGen'ed like inputs.Quentin Colombet2016-09-231-0/+47
| | | | | | | Make sure the entries written to mimic the behavior of TableGen are sane. llvm-svn: 282220
OpenPOWER on IntegriCloud