summaryrefslogtreecommitdiffstats
path: root/llvm/lib/Target/AArch64/AArch64LegalizerInfo.cpp
Commit message (Collapse)AuthorAgeFilesLines
* Revert r319691: [globalisel][tablegen] Split atomic load/store into separate ↵Daniel Sanders2017-12-051-8/+0
| | | | | | | | opcode and enable for AArch64. Some concerns were raised with the direction. Revert while we discuss it and look into an alternative llvm-svn: 319739
* [globalisel][tablegen] Split atomic load/store into separate opcode and ↵Daniel Sanders2017-12-041-0/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | enable for AArch64. This patch splits atomics out of the generic G_LOAD/G_STORE and into their own G_ATOMIC_LOAD/G_ATOMIC_STORE. This is a pragmatic decision rather than a necessary one. Atomic load/store has little in implementation in common with non-atomic load/store. They tend to be handled very differently throughout the backend. It also has the nice side-effect of slightly improving the common-case performance at ISel since there's no longer a need for an atomicity check in the matcher table. All targets have been updated to remove the atomic load/store check from the G_LOAD/G_STORE path. AArch64 has also been updated to mark G_ATOMIC_LOAD/G_ATOMIC_STORE legal. There is one issue with this patch though which also affects the extending loads and truncating stores. The rules only match when an appropriate G_ANYEXT is present in the MIR. For example, (G_ATOMIC_STORE (G_TRUNC:s16 (G_ANYEXT:s32 (G_ATOMIC_LOAD:s16 X)))) will match but: (G_ATOMIC_STORE (G_ATOMIC_LOAD:s16 X)) will not. This shouldn't be a problem at the moment, but as we get better at eliminating extends/truncates we'll likely start failing to match in some cases. The current plan is to fix this in a patch that changes the representation of extending-load/truncating-store to allow the MMO to describe a different type to the operation. llvm-svn: 319691
* GlobalISel: Enable the legalization of G_MERGE_VALUES and G_UNMERGE_VALUESVolkan Keles2017-12-011-0/+17
| | | | | | | | | | | | | | Summary: LegalizerInfo assumes all G_MERGE_VALUES and G_UNMERGE_VALUES instructions are legal, so it is not possible to legalize vector operations on illegal vector types. This patch fixes the problem by removing the related check and adding default actions for G_MERGE_VALUES and G_UNMERGE_VALUES. Reviewers: qcolombet, ab, dsanders, aditya_nandakumar, t.p.northover, kristof.beyls Reviewed By: dsanders Subscribers: rovka, javed.absar, igorb, llvm-commits Differential Revision: https://reviews.llvm.org/D39823 llvm-svn: 319524
* [aarch64][globalisel] Legalize G_ATOMIC_CMPXCHG_WITH_SUCCESS and G_ATOMICRMW_*Daniel Sanders2017-11-301-1/+3
| | | | | | | | | | | G_ATOMICRMW_* is generally legal on AArch64. The exception is G_ATOMICRMW_NAND. G_ATOMIC_CMPXCHG_WITH_SUCCESS needs to be lowered to G_ATOMIC_CMPXCHG with an external comparison. Note that IRTranslator doesn't generate these instructions yet. llvm-svn: 319466
* Fix VS2017 narrowing conversion warning. NFCISimon Pilgrim2017-11-281-1/+1
| | | | llvm-svn: 319240
* [aarch64][globalisel] Define G_ATOMIC_CMPXCHG and G_ATOMICRMW_* and make ↵Daniel Sanders2017-11-281-1/+18
| | | | | | | | | | | | | | | | them legal The IRTranslator cannot generate these instructions at the moment so there's no issue with not having implemented ISel for them yet. D40092 will add G_ATOMIC_CMPXCHG_WITH_SUCCESS and G_ATOMICRMW_* to the IRTranslator and a further patch will add support for lowering G_ATOMIC_CMPXCHG_WITH_SUCCESS into G_ATOMIC_CMPXCHG with an external success check via the `Lower` action. The separation of G_ATOMIC_CMPXCHG_WITH_SUCCESS and G_ATOMIC_CMPXCHG is to import SelectionDAG rules while still supporting targets that prefer to custom lower the original LLVM-IR-like operation. llvm-svn: 319216
* 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] Enable legalizing non-power-of-2 sized types.Kristof Beyls2017-11-071-41/+128
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This changes the interface of how targets describe how to legalize, see the below description. 1. Interface for targets to describe how to legalize. In GlobalISel, the API in the LegalizerInfo class is the main interface for targets to specify which types are legal for which operations, and what to do to turn illegal type/operation combinations into legal ones. For each operation the type sizes that can be legalized without having to change the size of the type are specified with a call to setAction. This isn't different to how GlobalISel worked before. For example, for a target that supports 32 and 64 bit adds natively: for (auto Ty : {s32, s64}) setAction({G_ADD, 0, s32}, Legal); or for a target that needs a library call for a 32 bit division: setAction({G_SDIV, s32}, Libcall); The main conceptual change to the LegalizerInfo API, is in specifying how to legalize the type sizes for which a change of size is needed. For example, in the above example, how to specify how all types from i1 to i8388607 (apart from s32 and s64 which are legal) need to be legalized and expressed in terms of operations on the available legal sizes (again, i32 and i64 in this case). Before, the implementation only allowed specifying power-of-2-sized types (e.g. setAction({G_ADD, 0, s128}, NarrowScalar). A worse limitation was that if you'd wanted to specify how to legalize all the sized types as allowed by the LLVM-IR LangRef, i1 to i8388607, you'd have to call setAction 8388607-3 times and probably would need a lot of memory to store all of these specifications. Instead, the legalization actions that need to change the size of the type are specified now using a "SizeChangeStrategy". For example: setLegalizeScalarToDifferentSizeStrategy( G_ADD, 0, widenToLargerAndNarrowToLargest); This example indicates that for type sizes for which there is a larger size that can be legalized towards, do it by Widening the size. For example, G_ADD on s17 will be legalized by first doing WidenScalar to make it s32, after which it's legal. The "NarrowToLargest" indicates what to do if there is no larger size that can be legalized towards. E.g. G_ADD on s92 will be legalized by doing NarrowScalar to s64. Another example, taken from the ARM backend is: for (unsigned Op : {G_SDIV, G_UDIV}) { setLegalizeScalarToDifferentSizeStrategy(Op, 0, widenToLargerTypesUnsupportedOtherwise); if (ST.hasDivideInARMMode()) setAction({Op, s32}, Legal); else setAction({Op, s32}, Libcall); } For this example, G_SDIV on s8, on a target without a divide instruction, would be legalized by first doing action (WidenScalar, s32), followed by (Libcall, s32). The same principle is also followed for when the number of vector lanes on vector data types need to be changed, e.g.: setAction({G_ADD, LLT::vector(8, 8)}, LegalizerInfo::Legal); setAction({G_ADD, LLT::vector(16, 8)}, LegalizerInfo::Legal); setAction({G_ADD, LLT::vector(4, 16)}, LegalizerInfo::Legal); setAction({G_ADD, LLT::vector(8, 16)}, LegalizerInfo::Legal); setAction({G_ADD, LLT::vector(2, 32)}, LegalizerInfo::Legal); setAction({G_ADD, LLT::vector(4, 32)}, LegalizerInfo::Legal); setLegalizeVectorElementToDifferentSizeStrategy( G_ADD, 0, widenToLargerTypesUnsupportedOtherwise); As currently implemented here, vector types are legalized by first making the vector element size legal, followed by then making the number of lanes legal. The strategy to follow in the first step is set by a call to setLegalizeVectorElementToDifferentSizeStrategy, see example above. The strategy followed in the second step "moreToWiderTypesAndLessToWidest" (see code for its definition), indicating that vectors are widened to more elements so they map to natively supported vector widths, or when there isn't a legal wider vector, split the vector to map it to the widest vector supported. Therefore, for the above specification, some example legalizations are: * getAction({G_ADD, LLT::vector(3, 3)}) returns {WidenScalar, LLT::vector(3, 8)} * getAction({G_ADD, LLT::vector(3, 8)}) then returns {MoreElements, LLT::vector(8, 8)} * getAction({G_ADD, LLT::vector(20, 8)}) returns {FewerElements, LLT::vector(16, 8)} 2. Key implementation aspects. How to legalize a specific (operation, type index, size) tuple is represented by mapping intervals of integers representing a range of size types to an action to take, e.g.: setScalarAction({G_ADD, LLT:scalar(1)}, {{1, WidenScalar}, // bit sizes [ 1, 31[ {32, Legal}, // bit sizes [32, 33[ {33, WidenScalar}, // bit sizes [33, 64[ {64, Legal}, // bit sizes [64, 65[ {65, NarrowScalar} // bit sizes [65, +inf[ }); Please note that most of the code to do the actual lowering of non-power-of-2 sized types is currently missing, this is just trying to make it possible for targets to specify what is legal, and how non-legal types should be legalized. Probably quite a bit of further work is needed in the actual legalizing and the other passes in GlobalISel to support non-power-of-2 sized types. I hope the documentation in LegalizerInfo.h and the examples provided in the various {Target}LegalizerInfo.cpp and LegalizerInfoTest.cpp explains well enough how this is meant to be used. This drops the need for LLT::{half,double}...Size(). Differential Revision: https://reviews.llvm.org/D30529 llvm-svn: 317560
* [AArch64][LegalizerInfo] Mark s128 G_BITCAST legalQuentin Colombet2017-10-161-1/+3
| | | | | | | We used to mark all G_BITCAST of 128-bit legal but only for vector types. Scalars of this size are just fine as well. llvm-svn: 315945
* [AArch64][GlobalISel] Make G_PHI of p0 types legal.Amara Emerson2017-10-081-1/+1
| | | | | | Differential Revision: https://reviews.llvm.org/D38621 llvm-svn: 315177
* [globalisel] Add a G_BSWAP instruction and support bswap using it.Daniel Sanders2017-09-191-0/+3
| | | | llvm-svn: 313633
* [AArch64][GlobalISel] Select all fpexts.Ahmed Bougacha2017-09-121-6/+7
| | | | | | | Tablegen already can select these: mark them as legal, remove the c++ code, and add tests for all types. llvm-svn: 313074
* [GISel]: Implement widenScalar for Legalizing G_PHIAditya Nandakumar2017-08-251-0/+3
| | | | | | https://reviews.llvm.org/D37018 llvm-svn: 311763
* [GISEl]: Translate phi into G_PHIAditya Nandakumar2017-08-231-0/+3
| | | | | | | | | | 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
* [GISel]: Support Widening G_ICMP's destination operand.Aditya Nandakumar2017-07-311-2/+4
| | | | | | | | | Updated AArch64 to widen destination to s32. https://reviews.llvm.org/D35737 Reviewed by Tim llvm-svn: 309579
* [globalisel][tablegen] Enable the import of rules involving fma.Daniel Sanders2017-07-181-1/+1
| | | | | | | | | | | | | | | | Summary: G_FMA was recently added to GlobalISel which enables the import of rules involving fma. Add the mapping to allow it. Reviewers: ab, t.p.northover, qcolombet, rovka, aditya_nandakumar Reviewed By: rovka Subscribers: kristof.beyls, javed.absar, igorb, llvm-commits Differential Revision: https://reviews.llvm.org/D35130 llvm-svn: 308308
* [GISel]: Enhance the MachineIRBuilder APIAditya Nandakumar2017-07-061-3/+2
| | | | | | | | | | | | | | | | | | | | Allows the MachineIRBuilder APIs to directly create registers (based on LLT or TargetRegisterClass) as well as accept MachineInstrBuilders and implicitly converts to register(with getOperand(0).getReg()). Eg usage: LLT s32 = LLT::scalar(32); auto C32 = Builder.buildConstant(s32, 32); auto Tmp = Builder.buildInstr(TargetOpcode::G_SUB, s32, C32, OtherReg); auto Tmp2 = Builder.buildInstr(Opcode, DstReg, Builder.buildConstant(s32, 31)); .... Only a few methods added for now. Reviewed by Tim llvm-svn: 307302
* GlobalISel: add G_IMPLICIT_DEF instruction.Tim Northover2017-06-301-0/+3
| | | | | | | | | 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
* AArch64: legalize G_EXTRACT operations.Tim Northover2017-06-261-0/+6
| | | | | | | This is the dual problem to legalizing G_INSERTs so most of the code and testing was cribbed from there. llvm-svn: 306328
* 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
* GlobalISel: constrain G_INSERT to inserting just one value per instruction.Tim Northover2017-03-031-3/+2
| | | | | | | It's much easier to reason about single-value inserts and no-one was actually using the variadic variants before. llvm-svn: 296923
* GlobalISel: legalize va_arg on AArch64.Tim Northover2017-02-151-0/+78
| | | | | | | | Uses a Custom implementation because the slot sizes being a multiple of the pointer size isn't really universal, even for the architectures that do have a simple "void *" va_list. llvm-svn: 295255
* GlobalISel: deal with new G_PTR_MASK instruction on AArch64.Tim Northover2017-02-141-0/+2
| | | | | | It's just an AND-immediate instruction for us, surprisingly simple to select. llvm-svn: 295104
* GlobalISel: legalize G_FPOW to a libcall on AArch64.Tim Northover2017-02-081-2/+4
| | | | | | There's no instruction to implement it. llvm-svn: 294531
* GlobalISel: expand mul-with-overflow into mul-hi on AArch64.Tim Northover2017-02-081-1/+4
| | | | | | | | AArch64 has specific instructions to multiply two numbers at double the width and produce the high part of the result. These can be used to implement LLVM's mul.with.overflow instructions fairly simply. Helps with C++ operator new[]. llvm-svn: 294519
* GlobalISel: select G_VASTART on iOS AArch64.Tim Northover2017-02-081-0/+2
| | | | | | | The AAPCS ABI is substantially more complicated so that's coming in a separate patch. For now we can generate correct code for iOS though. llvm-svn: 294493
* GlobalISel: legalize narrow G_SELECTS on AArch64.Tim Northover2017-02-061-1/+4
| | | | | | Otherwise there aren't any patterns to select them. llvm-svn: 294261
* GlobalISel: legalize G_INSERT instructionsTim Northover2017-02-061-0/+12
| | | | | | | We don't handle all cases yet (see arm64-fallback.ll for an example), but this is enough to cover most common C++ code so it's a good place to start. llvm-svn: 294247
* [GlobalISel] Add support for indirectbrKristof Beyls2017-01-301-0/+1
| | | | | | Differential Revision: https://reviews.llvm.org/D28079 llvm-svn: 293470
* [AArch64][LegalizerInfo] Specify the type of the opcode.Quentin Colombet2017-01-271-6/+6
| | | | | | | This is an attempt to fix the win7 bot that does not seem to be very good at infering the type when it gets used in an initiliazer list. llvm-svn: 293246
* Revert "[AArch64][LegalizerInfo] Specify the type of the initialization list."Quentin Colombet2017-01-271-76/+70
| | | | | | | | This reverts commit r293238. Even with that the win7 bot is still failing: http://lab.llvm.org:8011/builders/lld-x86_64-win7/builds/3862 llvm-svn: 293245
* [AArch64][LegalizerInfo] Specify the type of the initialization list.Quentin Colombet2017-01-271-70/+76
| | | | | | | This is an attempt to fix the win7 bot that does not seem to be very good at infering the type. llvm-svn: 293238
* [AArch64][GlobalISel] Legalize narrow scalar fp->int conversions.Ahmed Bougacha2017-01-231-3/+2
| | | | | | | | | Since we're now avoiding operations using narrow scalar integer types, we have to legalize the integer side of the FP conversions. This requires teaching the legalizer how to do that. llvm-svn: 292828
* [AArch64][GlobalISel] Legalize narrow scalar ops again.Ahmed Bougacha2017-01-231-1/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Since r279760, we've been marking as legal operations on narrow integer types that have wider legal equivalents (for instance, G_ADD s8). Compared to legalizing these operations, this reduced the amount of extends/truncates required, but was always a weird legalization decision made at selection time. So far, we haven't been able to formalize it in a way that permits the selector generated from SelectionDAG patterns to be sufficient. Using a wide instruction (say, s64), when a narrower instruction exists (s32) would introduce register class incompatibilities (when one narrow generic instruction is selected to the wider variant, but another is selected to the narrower variant). It's also impractical to limit which narrow operations are matched for which instruction, as restricting "narrow selection" to ranges of types clashes with potentially incompatible instruction predicates. Concerns were also raised regarding MIPS64's sign-extended register assumptions, as well as wrapping behavior. See discussions in https://reviews.llvm.org/D26878. Instead, legalize the operations. Should we ever revert to selecting these narrow operations, we should try to represent this more accurately: for instance, by separating a "concrete" type on operations, and an "underlying" type on vregs, we could move the "this narrow-looking op is really legal" decision to the legalizer, and let the selector use the "underlying" vreg type only, which would be guaranteed to map to a register class. In any case, we eventually should mitigate: - the performance impact by selecting no-op extract/truncates to COPYs (which we currently do), and the COPYs to register reuses (which we don't do yet). - the compile-time impact by optimizing away extract/truncate sequences in the legalizer. llvm-svn: 292827
* [AArch64][GlobalISel] Widen scalar int->fp conversions.Ahmed Bougacha2017-01-201-1/+7
| | | | | | | It's incorrect to ignore the higher bits of the integer source. Teach the legalizer how to widen it. llvm-svn: 292563
* [GlobalISel] Pointers are legal operands for G_SELECT on AArch64Kristof Beyls2017-01-191-1/+1
| | | | | | Differential Revision: https://reviews.llvm.org/D28805 llvm-svn: 292481
* GlobalISel: allow truncating pointer casts on AArch64.Tim Northover2016-10-311-1/+3
| | | | llvm-svn: 285615
* GlobalISel: rename legalizer components to match others.Tim Northover2016-10-141-0/+202
The previous names were both misleading (the MachineLegalizer actually contained the info tables) and inconsistent with the selector & translator (in having a "Machine") prefix. This should make everything sensible again. The only functional change is the name of a couple of command-line options. llvm-svn: 284287
OpenPOWER on IntegriCloud