summaryrefslogtreecommitdiffstats
path: root/llvm/lib
Commit message (Collapse)AuthorAgeFilesLines
* [ThinLTO] Ensure sanitizer passes are runTeresa Johnson2017-11-081-0/+3
| | | | | | | | | | | | | | | | | | Summary: In ThinLTO compilation, we exit populateModulePassManager early and were not adding PM extension passes meant to run at the end of the pipeline. This includes sanitizer passes. Add these passes before the early exit. A test will be added to projects/compiler-rt. Reviewers: pcc Subscribers: mehdi_amini, inglorion, llvm-commits Differential Revision: https://reviews.llvm.org/D39565 llvm-svn: 317714
* [X86] Don't call validateInstruction from MatchAndEmitInstruction when ↵Craig Topper2017-11-081-2/+2
| | | | | | | | MatchingInlineAsm is set. The MCInst won't be populated. Without this we can't parse gather instructions in ms inline asm blocks. The validateInstruction function was introduced in r316700 to check gather constraints. llvm-svn: 317713
* [ValueTracking] Use APInt::isNullValue/isOneValue which are more efficient ↵Craig Topper2017-11-081-3/+6
| | | | | | for large APInts. llvm-svn: 317712
* [WebAssembly] Call signExtend to get sign extended registerDan Gohman2017-11-081-1/+1
| | | | | | | | Patch by Jatin Bhateja! Differential Revision: https://reviews.llvm.org/D39529 llvm-svn: 317710
* [WebAssembly] Revise the strategy for inline asm.Dan Gohman2017-11-082-6/+25
| | | | | | | | | | | | | | | | | | | | | | Previously, an "r" constraint would mean the compiler provides a value on WebAssembly's operand stack. This was tricky to use properly, particularly since it isn't possible to declare a new local from within an inline asm string. With this patch, "r" provides the value in a WebAssembly local, and the local index is provided to the inline asm string. This requires inline asm to use get_local and set_local to read the register. This does potentially result in larger code size, however inline asm should hopefully be quite rare in WebAssembly. This also means that the "m" constraint can no longer be supported, as WebAssembly has nothing like a "memory operand" that includes an implicit get_local. This fixes PR34599 for the wasm32-unknown-unknown-wasm target (though not for the ELF target). llvm-svn: 317707
* NFC: Rename MCSafeSEHFragment to MCSymbolIdFragmentAdrian McCarthy2017-11-083-9/+9
| | | | | | | | | | | | | | | Summary: This fragment emits a symbol ID and will be useful for more than just Safe SEH tables (e.g., I plan to re-use it for Control Flow Guard tables). This is simply a rename refactor. Reviewers: rnk Subscribers: llvm-commits, hiraditya Differential Revision: https://reviews.llvm.org/D39770 llvm-svn: 317703
* Handle inlined variables in SelectionDAGBuilder::EmitFuncArgumentDbgValue().Adrian Prantl2017-11-081-6/+0
| | | | | | | | | | | | | | | | | In 2010 a commit with no testcase and no further explanation explicitly disabled the handling of inlined variables in EmitFuncArgumentDbgValue(). I don't think there is a good reason for this any more and re-enabling this adds debug locations for variables associated with an LLVM function argument in functions that are inlined into the first basic block. The only downside of doing this is that we may insert a DBG_VALUE before the inlined scope, but (1) this could be filtered out later, and (2) LiveDebugValues will not propagate it into subsequent basic blocks if they don't dominate the variable's lexical scope, so this seems like a small price to pay. rdar://problem/26228128 llvm-svn: 317702
* [RISCV] Initial support for function callsAlex Bradbury2017-11-088-4/+186
| | | | | | | | | Note that this is just enough for simple function call examples to generate working code. Support for varargs etc follows in future patches. Differential Revision: https://reviews.llvm.org/D29936 llvm-svn: 317691
* [RISCV] Codegen for conditional branchesAlex Bradbury2017-11-088-4/+118
| | | | | | | | | | | | | | | | | | | | A good portion of this patch is the extra functions that needed to be implemented to support the test case. e.g. storeRegToStackSlot, loadRegFromStackSlot, eliminateFrameIndex. Setting ISD::BR_CC to Expand may appear non-obvious on an architecture with branch+cmp instructions. However, I found it much easier to deal with matching the expanded form. I had to change simm13_lsb0 and simm21_lsb0 to inherit from the Operand<OtherVT> class rather than Operand<i32> in order to keep tablegen happy. This isn't a big deal, but it does seem a shame to lose the uniformity across immediate types when there's not an obvious benefit (I'm hoping a tablegen expert will educate me on what I'm missing here!). Differential Revision: https://reviews.llvm.org/D29935 llvm-svn: 317690
* [RISCV] Codegen support for memory operations on global addressesAlex Bradbury2017-11-085-22/+99
| | | | | | Differential Revision: https://reviews.llvm.org/D39103 llvm-svn: 317688
* [RISCV] Codegen support for memory operationsAlex Bradbury2017-11-084-0/+47
| | | | | | | | | This required the implementation of RISCVTargetInstrInfo::copyPhysReg. Support for lowering global addresses follow in the next patch. Differential Revision: https://reviews.llvm.org/D29934 llvm-svn: 317685
* [RISCV] Codegen support for materializing constantsAlex Bradbury2017-11-081-0/+24
| | | | | | Differential Revision: https://reviews.llvm.org/D39101 llvm-svn: 317684
* [Analysis] Fix merging TBAA tags with different final access typesIvan A. Kosarev2017-11-081-24/+13
| | | | | | | | | | | | | | | | | | | | | There are cases when we have to merge TBAA access tags with the same base access type, but different final access types. For example, accesses to different members of the same structure may be vectorized into a single load or store instruction. Since we currently assume that the tags to merge always share the same final access type, we incorrectly return a tag that describes an access to one of the original final access types as the generic tag. This patch fixes that by producing generic tags for the common type and not the final access types of the original tags. Resolves: PR35225: Wrong tbaa metadata after load store vectorizer due to recent change https://bugs.llvm.org/show_bug.cgi?id=35225 Differential Revision: https://reviews.llvm.org/D39732 llvm-svn: 317682
* [mips] Guard indirect and tailcall pseudo instructions correctly.Simon Dardis2017-11-083-11/+23
| | | | | | | | | | | Previously these pseudo instructions were not guarded by ISA, so their select was dependant on the ordering of the entries in the DAG matcher. Reviewers: atanasyan Differential Revision: https://reviews.llvm.org/D39723 llvm-svn: 317681
* BasicAA: fix bug where we would return partialalias instead of noaliasNuno Lopes2017-11-081-3/+3
| | | | | | | | | | | | | | | My fix is conservative and will make us return may-alias instead. The test case is: check(gep(x, 0), n, gep(x, n), -1) with n == sizeof(x) Here, the first value accesses the whole object, but the second access doesn't access anything. The semantics of -1 is read until the end of the object, which in this case means read nothing. No test case, since isn't trivial to exploit this one, but I've proved it correct. llvm-svn: 317680
* [NFCI] Ensure TargetOpcode::* are compatible with guessInstructionProperties=0Alex Bradbury2017-11-081-3/+1
| | | | | | | | | | | | | | | | | | | rL162640 introduced CodeGenTarget::guessInstructionProperties. If a target sets guessInstructionProperties=0 in its FooInstrInfo, tablegen will error if it has to guess properties from patterns. Unfortunately, guessInstructionProperties=0 can't be used with current upstream LLVM as instructions in the TargetOpcode namespace are always included and sometimes have inferred properties for mayLoad, mayStore, and hasSideEffects. This patch provides the simplest possible fix to this problem, setting default values for these fields in the TargetOpcode scope. There is no intended functional change, as the explicitly set properties should match what was previously inferred. A number of the instructions had hasSideEffects=1 inferred unintentionally. This patch makes it explicit, while future patches (such as D37097) correct the property. Differential Revision: https://reviews.llvm.org/D37065 llvm-svn: 317674
* DAG: Add computeKnownBitsForFrameIndexMatt Arsenault2017-11-082-5/+14
| | | | | | | | | | | | | Some of the AMDGPU stack addressing modes require knowing the sign bit is zero. We used to accomplish this by custom lowering frame indexes, and then putting an AssertZext around a TargetFrameIndex. This required specifically looking for the AssextZext + frame index pattern which was moderately disgusting. The same could probably be accomplished with a target specific node, but would still require special handling of frame indexes. llvm-svn: 317671
* Revert "[CGP] Enable extending scope of optimizeMemoryInst"Serguei Katkov2017-11-081-1/+1
| | | | | | Revert the patch r317665 causing buildbot failures. llvm-svn: 317667
* [CGP] Enable extending scope of optimizeMemoryInstSerguei Katkov2017-11-081-1/+1
| | | | | | | | | | | This patch enables the folding of address computation in memory instruction in case adress is represented by Phi node. The inputs of Phi node might be different in base register. Differential Revision: https://reviews.llvm.org/D36073 llvm-svn: 317665
* [X86] Add patterns to fold EVEX store with EVEX encoded vcvtps2ph ↵Craig Topper2017-11-081-11/+23
| | | | | | instructions. Remove bad pattern that had vf432 vcvtps2ph storing 128-bits. llvm-svn: 317662
* [X86] Allow legacy vcvtps2ph intrinsics to select EVEX encoded instructions. ↵Craig Topper2017-11-082-18/+16
| | | | | | | | Rely on EVEX->VEX to convert back. Missed store folding opportunities will be fixed in a subsequent commit. llvm-svn: 317661
* Convert FileOutputBuffer::commit to Error.Rafael Espindola2017-11-081-5/+5
| | | | llvm-svn: 317656
* Revert "Reapply: Allow yaml2obj to order implicit sections for ELF"Dave Lee2017-11-081-1/+1
| | | | | | This reverts commit r317646. llvm-svn: 317654
* Convert FileOutputBuffer to Expected. NFC.Rafael Espindola2017-11-082-12/+11
| | | | llvm-svn: 317649
* Target/TargetInstrInfo.h -> CodeGen/TargetInstrInfo.h to match layeringDavid Blaikie2017-11-08172-209/+209
| | | | | | | | This header includes CodeGen headers, and is not, itself, included by any Target headers, so move it into CodeGen to match the layering of its implementation. llvm-svn: 317647
* Reapply: Allow yaml2obj to order implicit sections for ELFDave Lee2017-11-081-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | Summary: This change allows yaml input to control the order of implicitly added sections (`.symtab`, `.strtab`, `.shstrtab`). The order is controlled by adding a placeholder section of the given name to the Sections field. This change is to support changes in D39582, where it is desirable to control the location of the `.dynsym` section. This reapplied version fixes: 1. use of a function call within an assert 2. failing lld test which has an unnamed section Additionally, one more test to cover the unnamed section failure. Reviewers: compnerd, jakehehrlich Reviewed By: jakehehrlich Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D39749 llvm-svn: 317646
* AMDGPU: Set correct sched model on v_mad_u64_u32Matt Arsenault2017-11-081-0/+2
| | | | llvm-svn: 317645
* Revert rL317618Mitch Phillips2017-11-081-319/+140
| | | | | | | | | | The implemented pass fails and is breaking a large number of unit tests. Example: http://lab.llvm.org:8011/builders/clang-with-lto-ubuntu/builds/5777/steps/build-stage3-compiler/logs/stdio This reverts commit rL317618 llvm-svn: 317641
* Attribute nonlazybind should not affect calls to functions with hidden ↵Sriraman Tallam2017-11-082-9/+11
| | | | | | | | visibility. Differential Revision: https://reviews.llvm.org/D39625 llvm-svn: 317639
* Revert "Allow yaml2obj to order implicit sections for ELF"Dave Lee2017-11-071-1/+1
| | | | | | | | Also, revert "Fix build bots after r317622" This reverts commit r317622, r317626. llvm-svn: 317630
* [NVPTX] Implement __nvvm_atom_add_gen_d builtin.Justin Lebar2017-11-072-0/+14
| | | | | | | | | | | | | | | Summary: This just seems to have been an oversight. We already supported the f64 atomic add with an explicit scope (e.g. "cta"), but not the scopeless version. Reviewers: tra Subscribers: jholewinski, sanjoy, cfe-commits, llvm-commits, hiraditya Differential Revision: https://reviews.llvm.org/D39638 llvm-svn: 317623
* Allow yaml2obj to order implicit sections for ELFDave Lee2017-11-071-1/+1
| | | | | | | | | | | | | | | | | | | | Summary: This change allows yaml input to control the order of implicitly added sections (`.symtab`, `.strtab`, `.shstrtab`). The order is controlled by adding a placeholder section of the given name to the Sections field. This change is to support changes in D39582, where it is desirable to control the location of the `.dynsym` section. Reviewers: compnerd, jakehehrlich Reviewed By: jakehehrlich Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D39749 llvm-svn: 317622
* [SLPVectorizer] Failure to beneficially vectorize 'copyable' elements in ↵Dinar Temirbulatov2017-11-071-140/+319
| | | | | | | | | | | | | | | | | | | | | | | | | | integer binary ops. Patch tries to improve vectorization of the following code: void add1(int * __restrict dst, const int * __restrict src) { *dst++ = *src++; *dst++ = *src++ + 1; *dst++ = *src++ + 2; *dst++ = *src++ + 3; } Allows to vectorize even if the very first operation is not a binary add, but just a load. Fixed PR34619 and other issues related to previous commit. Reviewers: spatel, mzolotukhin, mkuper, hfinkel, RKSimon, filcab, ABataev Reviewed By: ABataev, RKSimon Subscribers: llvm-commits, RKSimon Differential Revision: https://reviews.llvm.org/D28907 llvm-svn: 317618
* Extend SpecialCaseList to allow users to blame matches on entries in the file.Mitch Phillips2017-11-071-46/+37
| | | | | | | | | | | | | | | | | | | | | Summary: Extends SCL functionality to allow users to find the line number in the file the SCL is built from through SpecialCaseList::inSectionBlame(...). Also removes the need to compile the SCL before use. As the matcher now contains a list of regexes to test against instead of a single regex, the regexes can be individually built on each insertion rather than one large compilation at the end of construction. This change also fixes a bug where blank lines would cause the parser to become out-of-sync with the line number. An error on line `k` was being reported as being on line `k - num_blank_lines_before_k`. Note: This change has a cyclical dependency on D39486. Both these changes must be submitted at the same time to avoid a build breakage. Reviewers: vlad.tsyrklevich Reviewed By: vlad.tsyrklevich Subscribers: kcc, pcc, llvm-commits Differential Revision: https://reviews.llvm.org/D39485 llvm-svn: 317617
* [CodeGenPrepare] Fix typo in comment. NFCCraig Topper2017-11-071-1/+1
| | | | llvm-svn: 317614
* Use new vector insert half-word and byte instructions when we see ↵Graham Yiu2017-11-072-3/+33
| | | | | | | | insertelement on '8 x i16' and '16 x i8' types. Also extended existing lit testcase to cover these cases. Differential Revision: https://reviews.llvm.org/D34630 llvm-svn: 317613
* [DWARFv5] Support DW_FORM_strp in the .debug_line header.Paul Robinson2017-11-076-27/+31
| | | | | | | | Supporting this form in .debug_line.dwo will be done as a follow-up. Differential Revision: https://reviews.llvm.org/D33155 llvm-svn: 317607
* Recommit r317510 "[InstCombine] Pull shifts through a select plus binop with ↵Craig Topper2017-11-071-27/+82
| | | | | | | | | | | | | | | | constant" The hexagon test should be fixed now. Original commit message: This pulls shifts through a select+binop with a constant where the select conditionally executes the binop. We already do this for just the binop, but not with the select. This can allow us to get the select closer to other selects to enable removing one. Differential Revision: https://reviews.llvm.org/D39222 llvm-svn: 317600
* [InstCombine] Update stale comment. NFCCraig Topper2017-11-071-2/+1
| | | | | | Datalayout is no longer optional so the comment didn't match what the code currently does. llvm-svn: 317594
* [Hexagon] Make a test more flexible in HexagonLoopIdiomRecognitionKrzysztof Parzyszek2017-11-071-18/+51
| | | | | | | | | An "or" that sets the sign-bit can be replaced with a "xor", if the sign-bit was known to be clear before. With some changes to instruction combining, the simple sign-bit check was failing. Replace it with a more flexible one to catch more cases. llvm-svn: 317592
* [AArch64][SVE] Asm: Add support for (ADD|SUB)_ZZZFlorian Hahn2017-11-073-0/+60
| | | | | | | | | | | | Patch [5/5] in a series to add assembler/disassembler support for AArch64 SVE unpredicated ADD/SUB instructions. Patch by Sander De Smalen. Reviewed by: rengolin Differential Revision: https://reviews.llvm.org/D39091 llvm-svn: 317591
* [AArch64][SVE] Asm: Add SVE (Z) Register definitions and parsing supportFlorian Hahn2017-11-075-1/+330
| | | | | | | | | | | | | | | | | | | | | Patch [3/5] in a series to add assembler/disassembler support for AArch64 SVE unpredicated ADD/SUB instructions. To summarise, this patch adds: * SVE register definitions * Methods to parse SVE register operands * Methods to print SVE register operands * RegKind SVEDataVector to distinguish it from other data types like scalar register or Neon vector. * k_SVEDataRegister and SVEDataRegOp to describe SVE registers (which will be extended by further patches with e.g. ElementWidth and the shift-extend type). Patch by Sander De Smalen. Reviewed by: rengolin Differential Revision: https://reviews.llvm.org/D39089 llvm-svn: 317590
* [SelectionDAG] Fix typo in comment. NFCCraig Topper2017-11-071-1/+1
| | | | llvm-svn: 317588
* [AArch64][SVE] Asm: Set SVE as unsupported feature for existing scheduler ↵Florian Hahn2017-11-078-0/+16
| | | | | | | | | | | | | | | | models. Patch [4/5] in a series to add assembler/disassembler support for AArch64 SVE unpredicated ADD/SUB instructions. We add SVE as unsupported feature for CPUs that don't have SVE to prevent errors from scheduler models saying it lacks information for these instructions. Patch by Sander De Smalen. Reviewed by: rengolin Differential Revision: https://reviews.llvm.org/D39090 llvm-svn: 317582
* Reland "Correct dwarf unwind information in function epilogue for X86"Petar Jovanovic2017-11-0710-18/+481
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Reland r317100 with minor fix regarding ComputeCommonTailLength function in BranchFolding.cpp. Skipping top CFI instructions block needs to executed on several more return points in ComputeCommonTailLength(). Original r317100 message: "Correct dwarf unwind information in function epilogue for X86" This patch aims to provide correct dwarf unwind information in function epilogue for X86. It consists of two parts. The first part inserts CFI instructions that set appropriate cfa offset and cfa register in emitEpilogue() in X86FrameLowering. This part is X86 specific. The second part is platform independent and ensures that: - CFI instructions do not affect code generation - Unwind information remains correct when a function is modified by different passes. This is done in a late pass by analyzing information about cfa offset and cfa register in BBs and inserting additional CFI directives where necessary. Changed CFI instructions so that they: - are duplicable - are not counted as instructions when tail duplicating or tail merging - can be compared as equal Added CFIInstrInserter pass: - analyzes each basic block to determine cfa offset and register valid at its entry and exit - verifies that outgoing cfa offset and register of predecessor blocks match incoming values of their successors - inserts additional CFI directives at basic block beginning to correct the rule for calculating CFA Having CFI instructions in function epilogue can cause incorrect CFA calculation rule for some basic blocks. This can happen if, due to basic block reordering, or the existence of multiple epilogue blocks, some of the blocks have wrong cfa offset and register values set by the epilogue block above them. CFIInstrInserter is currently run only on X86, but can be used by any target that implements support for adding CFI instructions in epilogue. Patch by Violeta Vukobrat. llvm-svn: 317579
* [SLP] Fix PR35047: Fix default cost model for cast op in X86.Alexey Bataev2017-11-071-1/+1
| | | | | | | | | | | | | | | Summary: The cost calculation for default case on X86 target does not always follow correct wayt because of missing 4-th argument in `BaseT::getCastInstrCost()` call. Added this missing parameter. Reviewers: hfinkel, mkuper, RKSimon, spatel Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D39687 llvm-svn: 317576
* Mark intentional fall-through with LLVM_FALLTHROUGH.Kristof Beyls2017-11-071-0/+1
| | | | | | ... to silence gcc 7's default -Wimplicit-fallthrough. llvm-svn: 317573
* [AArch64][SVE] Asm: Replace 'IsVector' by 'RegKind' in AArch64AsmParser (NFC)Florian Hahn2017-11-072-46/+69
| | | | | | | | | | | | | | Patch [2/5] in a series to add assembler/disassembler support for AArch64 SVE unpredicated ADD/SUB instructions. This change is a non functional change that adds RegKind as an alternative to 'isVector' to prepare it for newer types (SVE data vectors and predicate vectors) that will be added in next patches (where the SVE data vector is added as part of this patch set) Patch by Sander De Smalen. Reviewed by: rengolin Differential Revision: https://reviews.llvm.org/D39088 llvm-svn: 317569
* Silence C4715 warning from MSVC (NFC).Kristof Beyls2017-11-071-0/+1
| | | | | | | | | The warning started triggering after r317560. This commit silences it in the same way as previously done in a similar situation, see http://lists.llvm.org/pipermail/llvm-commits/Week-of-Mon-20140915/236088.html llvm-svn: 317568
* [GlobalISel] Enable legalizing non-power-of-2 sized types.Kristof Beyls2017-11-076-209/+554
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
OpenPOWER on IntegriCloud