summaryrefslogtreecommitdiffstats
path: root/llvm/utils/TableGen
Commit message (Collapse)AuthorAgeFilesLines
...
* [TableGen] Use vector::append instead of looping and calling push_back. NFCCraig Topper2018-03-201-4/+2
| | | | | | Both vectors contain unsigned so we can just use append to do the copying. Not only is this shorter, but it should be able to predict the final size and only grow the vector once if needed. llvm-svn: 328033
* [TableGen] Use llvm::transform to simplify some loops. NFCICraig Topper2018-03-201-18/+12
| | | | llvm-svn: 328032
* [TableGen] Pass result of std::unique to vector::erase instead of ↵Craig Topper2018-03-201-2/+1
| | | | | | calculating a size and calling resize. llvm-svn: 328031
* [X86] Add phony registers for high halves of regs with low halvesKrzysztof Parzyszek2018-03-203-28/+81
| | | | | | | | | | | | | | | | | Registers E[A-D]X, E[SD]I, E[BS]P, and EIP have 16-bit subregisters that cover the low halves of these registers. This change adds artificial subregisters for the high halves in order to differentiate (in terms of register units) between the 32- and the low 16-bit registers. This patch contains parts that aim to preserve the calculated register pressure. This is in order to preserve the current codegen (minimize the impact of this patch). The approach of having artificial subregisters could be used to fix PR23423, but the pressure calculation would need to be changed. Differential Revision: https://reviews.llvm.org/D43353 llvm-svn: 328016
* [TableGen] When trying to reuse a scheduler class for instructions from an ↵Craig Topper2018-03-181-1/+14
| | | | | | | | | | | | InstRW, make sure we haven't already seen another InstRW containing this instruction on this CPU. This is similar to the check later when we remap some of the instructions from one class to a new one. But if we reuse the class we don't get to do that check. So many CPUs have violations of this check that I had to add a flag to the SchedMachineModel to allow it to be disabled. Hopefully we can get those cleaned up quickly and remove this flag. A lot of the violations are due to overlapping regular expressions, but that's not the only kind of issue it found. llvm-svn: 327808
* [TableGen] Remove unnecessary uses of make_range.Craig Topper2018-03-181-2/+2
| | | | llvm-svn: 327785
* [TableGen] Move some variables into for loop declaration. NFCCraig Topper2018-03-181-2/+1
| | | | | | They aren't needed after the loop. llvm-svn: 327784
* Fix some user facing typosSylvestre Ledru2018-03-171-2/+2
| | | | llvm-svn: 327776
* [X86] Added support for nocf_check attribute for indirect Branch TrackingOren Ben Simhon2018-03-171-0/+2
| | | | | | | | | | | | | | | X86 Supports Indirect Branch Tracking (IBT) as part of Control-Flow Enforcement Technology (CET). IBT instruments ENDBR instructions used to specify valid targets of indirect call / jmp. The `nocf_check` attribute has two roles in the context of X86 IBT technology: 1. Appertains to a function - do not add ENDBR instruction at the beginning of the function. 2. Appertains to a function pointer - do not track the target function of this pointer by adding nocf_check prefix to the indirect-call instruction. This patch implements `nocf_check` context for Indirect Branch Tracking. It also auto generates `nocf_check` prefixes before indirect branchs to jump tables that are guarded by range checks. Differential Revision: https://reviews.llvm.org/D41879 llvm-svn: 327767
* [X86] Add all of the MRM_C0-MRM_FF forms to the switch in ↵Craig Topper2018-03-121-27/+20
| | | | | | | | | | RecognizableInstr::emitInstructionSpecifier. NFC Remove the special casing for MRM_F8 by using HANDLE_OPTIONAL. This should be NFC as the forms that were missing aren't used by any instructions today. They exist in the enum so that we didn't have to put them in one at a time when instructions are added. But looks like we failed here. llvm-svn: 327298
* [MCSchedule] Always generate processor resource names.Andrea Di Biagio2018-03-081-2/+2
| | | | | | | | | | | | With this patch, the tablegen 'SubtargetEmitter' always generates processor resource names. The impact of this patch on the code size of other llvm tools is small. I have observed an average increase of 0.03% in code size when doing a release build of LLVM (on windows, using MSVC) with all the default backends. This change is done in preparation for the upcoming llvm-mca patch. llvm-svn: 326993
* [WebAssembly] Add except_ref as a first-class typeHeejin Ahn2018-03-081-0/+1
| | | | | | | | | | | | Summary: Add except_ref as a first-class type, according to the [[https://github.com/WebAssembly/exception-handling/blob/master/proposals/Level-1.md | Level 1 exception handling proposal ]]. Reviewers: dschuff Subscribers: jfb, sbc100, llvm-commits Differential Revision: https://reviews.llvm.org/D43706 llvm-svn: 326985
* TableGen: Use DefInit::getDef() instead of the type's getRecord()Nicolai Haehnle2018-03-051-14/+11
| | | | | | | | | | | The former simply makes more sense: we want to access the data here in the backend, not information about the type. More importantly, removing users of RecordRecTy::getRecord() allows us more freedom to refactor the frontend. Change-Id: Iee8905fd22cdb9b11c42ca03246c03d8fe4dd77f llvm-svn: 326699
* Shrink various scheduling tables by using narrower types.Benjamin Kramer2018-02-231-7/+12
| | | | | | 16 bits ought to be enough for everyone. This shrinks clang by ~1MB. llvm-svn: 325941
* [MachineOperand][Target] MachineOperand::isRenamable semantics changesGeoff Berry2018-02-233-3/+14
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: Add a target option AllowRegisterRenaming that is used to opt in to post-register-allocation renaming of registers. This is set to 0 by default, which causes the hasExtraSrcRegAllocReq/hasExtraDstRegAllocReq fields of all opcodes to be set to 1, causing MachineOperand::isRenamable to always return false. Set the AllowRegisterRenaming flag to 1 for all in-tree targets that have lit tests that were effected by enabling COPY forwarding in MachineCopyPropagation (AArch64, AMDGPU, ARM, Hexagon, Mips, PowerPC, RISCV, Sparc, SystemZ and X86). Add some more comments describing the semantics of the MachineOperand::isRenamable function and how it is set and maintained. Change isRenamable to check the operand's opcode hasExtraSrcRegAllocReq/hasExtraDstRegAllocReq bit directly instead of relying on it being consistently reflected in the IsRenamable bit setting. Clear the IsRenamable bit when changing an operand's register value. Remove target code that was clearing the IsRenamable bit when changing registers/opcodes now that this is done conservatively by default. Change setting of hasExtraSrcRegAllocReq in AMDGPU target to be done in one place covering all opcodes that have constant pipe read limit restrictions. Reviewers: qcolombet, MatzeB Subscribers: aemerson, arsenm, jyknight, mcrosier, sdardis, nhaehnle, javed.absar, tpr, arichardson, kristof.beyls, kbarton, fedor.sergeev, asb, rbar, johnrusso, simoncook, jordy.potman.lists, apazos, sabuasal, niosHD, escha, nemanjai, llvm-commits Differential Revision: https://reviews.llvm.org/D43042 llvm-svn: 325931
* Fix signed/unsigned comparison warning in AsmGenMatcher generated code. NFCI.Simon Pilgrim2018-02-171-4/+4
| | | | llvm-svn: 325428
* [GISel]: Make GlobalISelEmitter rule prioritization compatible with selectionDAGAditya Nandakumar2018-02-161-0/+12
| | | | | | | | | | | | This patch changes GlobalISelEmitter to rank patterns similar to how the DAG does it (ie it computes a score for a pattern and adds the added complexity to it). This is so that the decision tree for GISelSelector remains compatible with that of SelectionDAG. https://reviews.llvm.org/D43270 llvm-svn: 325401
* [X86][3DNOW] Teach decoder about AMD 3DNow! instrsRafael Auler2018-02-153-21/+30
| | | | | | | | | | | | | | | | | | | Summary: This patch makes the decoder understand old AMD 3DNow! instructions that have never been properly supported in the X86 disassembler, despite being supported in other subsystems. Hopefully this should make the X86 decoder more complete with respect to binaries containing legacy code. Reviewers: craig.topper Reviewed By: craig.topper Subscribers: llvm-commits, maksfb, bruno Differential Revision: https://reviews.llvm.org/D43311 llvm-svn: 325295
* [X86] Teach EVEX->VEX pass to turn VRNDSCALE into VROUND when bits 7:4 of ↵Craig Topper2018-02-131-1/+19
| | | | | | | | | | the immediate are 0 and the regular EVEX->VEX checks pass. Bits 7:4 control the scale part of the operation. If the scale is 0 the behavior is equivalent to VROUND. Fixes PR36246 llvm-svn: 324985
* [TargetSchedule] Fix r324582.Clement Courbet2018-02-091-1/+1
| | | | | | | Increment was using the wrong NumUnits (the one from the ProcResGroup and not the subunit). llvm-svn: 324727
* Fix missing field initializer warning in TableGen SubtargetEmitterDavid Blaikie2018-02-081-3/+4
| | | | llvm-svn: 324643
* [TargetSchedule] Expose sub-units of a ProcResGroup in MCProcResourceDesc.Clement Courbet2018-02-081-3/+39
| | | | | | | | | | | | | | | | | | Summary: Right now using a ProcResource automatically counts as usage of all super ProcResGroups. All this is done during codegen, so there is no way for schedulers to get this information at runtime. This adds the information of which individual ProcRes units are contained in a ProcResGroup in MCProcResourceDesc. Reviewers: gchatelet Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D43023 llvm-svn: 324582
* [CodeGenSchedule][NFC] Always emit ProcResourceUnits.Clement Courbet2018-02-051-0/+8
| | | | | | | | | | | | | | | | | Summary: Right now only the ProcResourceUnits that are directly referenced by instructions are emitted. This change emits all of them, so that analysis passes can use the information. This has no functional impact. It typically adds a few entries (e.g. 4 for X86/haswell) to the generated ProcRes table. Reviewers: gchatelet Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D42903 llvm-svn: 324228
* [TableGen][AsmMatcherEmitter] Fix tied-constraint checking for InstAliasesSander de Smalen2018-02-041-154/+188
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: This is a bit of a reimplementation the work done in https://reviews.llvm.org/D41446, since that patch only really works for tied operands of instructions, not aliases. Instead of checking the constraints based on the matched instruction's opcode, this patch uses the match-info's convert function to check the operand constraints for that specific instruction/alias. This is based on the matched operands for the instruction, not the resulting opcode of the MCInst. This patch adds the following enum/table to the *GenAsmMatcher.inc file: enum { Tie0_1_1, Tie0_1_2, Tie0_1_5, ... }; const char TiedAsmOperandTable[][3] = { /* Tie0_1_1 */ { 0, 1, 1 }, /* Tie0_1_2 */ { 0, 1, 2 }, /* Tie0_1_5 */ { 0, 1, 5 }, ... }; And it is referenced directly in the ConversionTable, like this: static const uint8_t ConversionTable[CVT_NUM_SIGNATURES][13] = { ... { CVT_95_addRegOperands, 1, CVT_95_addRegOperands, 2, CVT_Tied, Tie0_1_5, CVT_95_addRegOperands, 6, CVT_Done }, ... The Tie0_1_5 (and corresponding table) encodes that: * Result operand 0 is the operand to copy (which is e.g. done when building up the operands to the MCInst in convertToMCInst()) * Asm operands 1 and 5 should be the same operands (which is checked in checkAsmTiedOperandConstraints()). Reviewers: olista01, rengolin, fhahn, craig.topper, echristo, apazos, dsanders Reviewed By: olista01 Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D42293 llvm-svn: 324196
* [ARM][GISel] PR35965 Constrain RegClasses of nested instructions built from ↵Daniel Sanders2018-01-291-6/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Dst Pattern Summary: Apparently, we missed on constraining register classes of VReg-operands of all the instructions built from a destination pattern but the root (top-level) one. The issue exposed itself while selecting G_FPTOSI for armv7: the corresponding pattern generates VTOSIZS wrapped into COPY_TO_REGCLASS, so top-level COPY_TO_REGCLASS gets properly constrained, while nested VTOSIZS (or rather its destination virtual register to be exact) does not. Fixing this by issuing GIR_ConstrainSelectedInstOperands for every nested GIR_BuildMI. https://bugs.llvm.org/show_bug.cgi?id=35965 rdar://problem/36886530 Patch by Roman Tereshin Reviewers: dsanders, qcolombet, rovka, bogner, aditya_nandakumar, volkan Reviewed By: dsanders, qcolombet, rovka Subscribers: aemerson, javed.absar, kristof.beyls, llvm-commits Differential Revision: https://reviews.llvm.org/D42565 llvm-svn: 323692
* [TableGen][NFC]Remove dead variable.Clement Courbet2018-01-261-1/+0
| | | | llvm-svn: 323525
* [GlobalISel][TableGen] Fix the statistics for emitted pattersVolkan Keles2018-01-251-3/+3
| | | | | | | | | Collected statistics for the number of patterns emitted can be incorrect because rules can be grouped if OptimizeMatchTable is enabled. Increase the counter in RuleMatcher::emit(...) to avoid that. llvm-svn: 323391
* [TableGen] Add a way of getting the number of generic opcodes without ↵Benjamin Kramer2018-01-243-9/+18
| | | | | | | | | | including modular CodeGen headers. This is a bit of a hack, but removes a cycle that broke modular builds of LLVM. Of course the cycle is still there in form of a dependency on the .def file. llvm-svn: 323383
* [NFC] fix trivial typos in commentsHiroshi Inoue2018-01-241-1/+1
| | | | | | "the the" -> "the" llvm-svn: 323302
* [TableGen] Optimize the regex search.Benjamin Kramer2018-01-231-20/+76
| | | | | | | | | | | | | | | | llvm::Regex is still the slowest regex engine on earth, running it over all instructions on X86 takes a while. Extract a prefix and use a binary search to reduce the search space before we resort to regex matching. There are a couple of caveats here: - The generic opcodes are outside of the sorted enum. They're handled in an extra loop. - If there's a top-level bar we can't use the prefix trick. - We bail on top-level ?. This could be handled, but it's rare. This brings the time to generate X86GenInstrInfo.inc from 21s to 4.7s on my machine. llvm-svn: 323277
* [globalisel][tablegen] Honour priority order within nested instructions.Daniel Sanders2018-01-171-0/+13
| | | | | | | | | | | It appears that we haven't been prioritizing rules that contain nested instructions properly. InstructionOperandMatcher didn't override isHigherPriorityThan so it never compared the instructions/operands/predicates inside nested instructions. Fixes PR35926. Thanks to Diana Picus for the bug report. llvm-svn: 322754
* [GlobalISel][TableGen] Add support for SDNodeXFormVolkan Keles2018-01-161-26/+106
| | | | | | | | | | | | | | | | | | | | | | | | | | Summary: This patch adds CustomRenderer which renders the matched operands to the specified instruction. Targets can enable the matching of SDNodeXForm by adding a definition that inherits from GICustomOperandRenderer and GISDNodeXFormEquiv as follows. def gi_imm8 : GICustomOperandRenderer<"renderImm8”>, GISDNodeXFormEquiv<imm8_xform>; Custom renderer functions should be of the form: void render(MachineInstrBuilder &MIB, const MachineInstr &I); Reviewers: dsanders, ab, rovka Reviewed By: dsanders Subscribers: kristof.beyls, javed.absar, llvm-commits, mgrang, qcolombet Differential Revision: https://reviews.llvm.org/D42012 llvm-svn: 322582
* [X86] Revisit the fix I made years ago to make 'xchgl %eax, %eax' not encode ↵Craig Topper2018-01-161-2/+0
| | | | | | | | | | using the 0x90 encoding in 64-bit mode. Prior to this we had a separate instruction and register class that excluded eax to prevent matching the instruction that would encode with 0x90. This patch changes this to just use an InstAlias to force xchgl %eax, %eax to use XCHG32rr instruction in 64-bit mode. This gets rid of the separate instruction and register class. llvm-svn: 322532
* [TableGen][AsmMatcherEmitter] Generate assembler checks for tied operandsSander de Smalen2018-01-101-0/+155
| | | | | | | | | | | | | | | | | | | | Summary: This extends TableGen's AsmMatcherEmitter with code that generates a table with tied-operand constraints. The constraints are checked when parsing the instruction. If an operand is not equal to its tied operand, the assembler will give an error. Patch [2/3] in a series to add operand constraint checks for SVE's predicated ADD/SUB. Reviewers: olista01, rengolin, mcrosier, fhahn, craig.topper, evandro, echristo Reviewed By: fhahn Subscribers: javed.absar, llvm-commits Differential Revision: https://reviews.llvm.org/D41446 llvm-svn: 322166
* [mips] Improve diagnostics for instruction mappingAleksandar Beserminji2018-01-081-1/+6
| | | | | | | | | This patch improves diagnostic for case when mapped instruction does not contain a field listed under RowFields. Differential Revision: https://reviews.llvm.org/D41778 llvm-svn: 322004
* [X86] Don't put any EVEX_B instructions in the tablegen generated load ↵Craig Topper2018-01-071-2/+3
| | | | | | | | folding tables. EVEX_B means different things for memory and register forms. The instructions should not be considered equivalent. llvm-svn: 321954
* [TableGen] Make the ambiguous match debug messages from the ↵Craig Topper2018-01-061-0/+6
| | | | | | | | AsmMatcherEmitter slightly more useful. Don't report ambiguous matches on different variants. Print the variant number in the output. llvm-svn: 321938
* [TableGen] Add support of Intrinsics with multiple returnsHal Finkel2018-01-031-1/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | This change deals with intrinsics with multiple outputs, for example load instrinsic with address updated. DAG selection for Instrinsics could be done either through source code or tablegen. Handling all intrinsics in source code would introduce a huge chunk of repetitive code if we have a large number of intrinsic that return multiple values (see NVPTX as an example). While intrinsic class in tablegen supports multiple outputs, tablegen only supports Intrinsics with zero or one output on TreePattern. This appears to be a simple bug in tablegen that is fixed by this change. For Intrinsics defined as: def int_xxx_load_addr_updated: Intrinsic<[llvm_i32_ty, llvm_ptr_ty], [llvm_ptr_ty, llvm_i32_ty], []>; Instruction will be defined as: def L32_X: Inst<(outs reg:$d1, reg:$d2), (ins reg:$s1, reg:$s2), "ld32_x $d1, $d2, $s2", [(set i32:$d1, i32:$d2, (int_xxx_load_addr_updated i32:$s1, i32:$s2))]>; Patch by Wenbo Sun, thanks! Differential Revision: https://reviews.llvm.org/D32888 llvm-svn: 321704
* Avoid int to string conversion in Twine or raw_ostream contexts.Benjamin Kramer2017-12-283-37/+37
| | | | | | Some output changes from uppercase hex to lowercase hex, no other functionality change intended. llvm-svn: 321526
* [TableGen] Print more helpful information in case of type contradictionKrzysztof Parzyszek2017-12-212-21/+39
| | | | | | Dump the failing TreePattern. llvm-svn: 321282
* Do not generate an empty switch statement as it causes MSVC to issue ↵Aaron Ballman2017-12-201-4/+7
| | | | | | diagnostics about switch statements without case or default labels. llvm-svn: 321217
* TableGen: Allow setting SDNodeProperties on intrinsicsMatt Arsenault2017-12-208-52/+120
| | | | | | | | | | | | | | | | | Allows preserving MachineMemOperands on intrinsics through selection. For reasons I don't understand, this is a static property of the pattern and the selector deliberately goes out of its way to drop if not present. Intrinsics already inherit from SDPatternOperator allowing them to be used directly in instruction patterns. SDPatternOperator has a list of SDNodeProperty, but you currently can't set them on the intrinsic. Without SDNPMemOperand, when the node is selected any memory operands are always dropped. Allowing setting this on the intrinsics avoids needing to introduce another equivalent target node just to have SDNPMemOperand set. llvm-svn: 321212
* [globalisel][tablegen] Allow ImmLeaf predicates to use InstructionSelector ↵Daniel Sanders2017-12-201-12/+22
| | | | | | | | | members NFC for currently supported targets. This resolves a problem encountered by targets such as RISCV that reference `Subtarget` in ImmLeaf predicates. llvm-svn: 321176
* [AArch64][SVE] Re-submit patch series for ZIP1/ZIP2Sander de Smalen2017-12-201-11/+15
| | | | | | | | | | | This patch resubmits the SVE ZIP1/ZIP2 patch series consisting of of r320992, r320986, r320973, and r320970 by reverting https://reviews.llvm.org/rL321024. The issue that caused r321024 has been addressed in https://reviews.llvm.org/rL321158, so this patch-series should be safe to resubmit. llvm-svn: 321163
* Silence a bunch of implicit fallthrough warningsAdrian Prantl2017-12-191-0/+1
| | | | llvm-svn: 321114
* [TableGen][GlobalISel] Reset the internal map of RuleMatchers just before ↵Quentin Colombet2017-12-191-3/+4
| | | | | | | | | | | | | | | | | | | the emission Between the creation of the last InstructionMatcher and the first emission of the related Rule, we need to clear the internal map of IDs. We used to do that right after the creation of the main InstructionMatcher when building the rule and although that worked, this is fragile because if for some reason some later code decides to create more InstructionMatcher before the final call to emit, then the IDs would be completely messed up. Move that to the beginning of "emit" so that the IDs are guarantee to be consistent. NFC. llvm-svn: 321053
* [TableGen][GlobalISel] Make the arguments of the Instruction and Operand ↵Quentin Colombet2017-12-181-18/+18
| | | | | | | | | | | | Matchers consistent Move InsnVarID and OpIdx at the beginning of the list of arguments for all the constructors of the OperandMatcher subclasses. This matches what we do for the InstructionMatcher. NFC. llvm-svn: 321031
* [TableGen][GlobalISel] Refactor optimizeRules related bit to allow code reuseQuentin Colombet2017-12-181-12/+23
| | | | | | | | | | | In theory, reapplying optimizeRules on each group matchers should give us a second nesting level on the matching table. In practice, we need more work to make that happen because all the predicates are actually not directly available through the predicate matchers list. NFC. llvm-svn: 321025
* Revert "[AArch64][SVE] Asm" changes, they broke libjpeg_turboReid Kleckner2017-12-181-15/+11
| | | | | | | | | | This reverts changes r320992, r320986, r320973, and r320970. r320970 by itself breaks the test case, and the rest depend on it. Test case will land soon. llvm-svn: 321024
* [TableGen][GlobalISel] Optimize MatchTable for faster instruction selectionQuentin Colombet2017-12-181-17/+194
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | *** Context *** Prior to this patchw, the table generated for matching instruction was straight forward but highly inefficient. Basically, each pattern generates its own set of self contained checks and actions. E.g., TableGen generated: // First pattern CheckNumOperand 3 CheckOpcode G_ADD ... Build ADDrr // Second pattern CheckNumOperand 3 CheckOpcode G_ADD ... Build ADDri // Third pattern CheckNumOperand 3 CheckOpcode G_SUB ... Build SUBrr *** Problem *** Because of that generation, a *lot* of check were redundant between each pattern and were checked every single time until we reach the pattern that matches. E.g., Taking the previous table, let say we are matching a G_SUB, that means we were going to check all the rules for G_ADD before looking at the G_SUB rule. In particular we are going to do: check 3 operands; PASS check G_ADD; FAIL ; Next rule check 3 operands; PASS (but we already knew that!) check G_ADD; FAIL (well it is still not true) ; Next rule check 3 operands; PASS (really!!) check G_SUB; PASS (at last :P) *** Proposed Solution *** This patch introduces a concept of group of rules (GroupMatcher) that share some predicates and only get checked once for the whole group. This patch only creates groups with one nesting level. Conceptually there is nothing preventing us for having deeper nest level. However, the current implementation is not smart enough to share the recording (aka capturing) of values. That limits its ability to do more sharing. For the given example the current patch will generate: // First group CheckOpcode G_ADD // First pattern CheckNumOperand 3 ... Build ADDrr // Second pattern CheckNumOperand 3 ... Build ADDri // Second group CheckOpcode G_SUB // Third pattern CheckNumOperand 3 ... Build SUBrr But if we allowed several nesting level, it could create a sub group for the checknumoperand 3. (We would need to call optimizeRules on the rules within a group.) *** Result *** With only one level of nesting, the instruction selection pass is up to 4x faster. For instance, one instruction now takes 500 checks, instead of 24k! With more nesting we could get in the tens I believe. Differential Revision: https://reviews.llvm.org/D39034 rdar://problem/34670699 llvm-svn: 321017
OpenPOWER on IntegriCloud