summaryrefslogtreecommitdiffstats
path: root/llvm/utils/TableGen/GlobalISelEmitter.cpp
Commit message (Collapse)AuthorAgeFilesLines
* TableGen/GlobalISel: Fix pattern matching of immarg literalsMatt Arsenault2020-01-091-15/+34
| | | | | | | | | | | | | | | | | For arguments that are not expected to be materialized with G_CONSTANT, this was emitting predicates which could never match. It was first adding a meaningless LLT check, which would always fail due to the operand not being a register. Infer the cases where a literal should check for an immediate operand, instead of a register This avoids needing to invent a special way of representing timm literal values. Also handle immediate arguments in GIM_CheckLiteralInt. The comments stated it handled isImm() and isCImm(), but that wasn't really true. This unblocks work on the selection of all of the complicated AMDGPU intrinsics in future commits.
* TableGen/GlobalISel: Add way for SDNodeXForm to work on timmMatt Arsenault2020-01-091-4/+47
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The current implementation assumes there is an instruction associated with the transform, but this is not the case for timm/TargetConstant/immarg values. These transforms should directly operate on a specific MachineOperand in the source instruction. TableGen would assert if you attempted to define an equivalent GISDNodeXFormEquiv using timm when it failed to find the instruction matcher. Specially recognize SDNodeXForms on timm, and pass the operand index to the render function. Ideally this would be a separate render function type that looks like void renderFoo(MachineInstrBuilder, const MachineOperand&), but this proved to be somewhat mechanically painful. Add an optional operand index which will only be passed if the transform should only look at the one source operand. Theoretically it would also be possible to only ever pass the MachineOperand, and the existing renderers would check the parent. I think that would be somewhat ugly for the standard usage which may want to inspect other operands, and I also think MachineOperand should eventually not carry a pointer to the parent instruction. Use it in one sample pattern. This isn't a great example, since the transform exists to satisfy DAG type constraints. This could also be avoided by just changing the MachineInstr's arbitrary choice of operand type from i16 to i32. Other patterns have nontrivial uses, but this serves as the simplest example. One flaw this still has is if you try to use an SDNodeXForm defined for imm, but the source pattern uses timm, you still see the "Failed to lookup instruction" assert. However, there is now a way to avoid it.
* TableGen/GlobalISel: Address fixmeMatt Arsenault2020-01-091-5/+9
| | | | Don't call computeAvailableFunctionFeatures for every instruction.
* TableGen/GlobalISel: Fix slightly wrong generated commentMatt Arsenault2020-01-091-1/+1
|
* TableGen/GlobalISel: Handle default operands that are usedMatt Arsenault2020-01-061-7/+37
| | | | | | | | | | Copy the logic from the existing handling in the DAG matcher emittter. This will enable some AMDGPU pattern cleanups without breaking GlobalISel tests, and eventually handle importing more patterns. The test is a bit annoying since the sections seem to randomly sort themselves if anything else is added in the future.
* [TableGen] Fixes -Wrange-loop-analysis warningsMark de Wever2019-12-221-4/+4
| | | | | | This avoids new warnings due to D68912 adds -Wrange-loop-analysis to -Wall. Differential Revision: https://reviews.llvm.org/D71807
* [PGO][PGSO] DAG.shouldOptForSize part.Hiroshi Yamauchi2019-11-211-0/+8
| | | | | | | | | | | | | | | Summary: (Split of off D67120) SelectionDAG::shouldOptForSize changes for profile guided size optimization. Reviewers: davidxl Subscribers: hiraditya, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D70095
* MatchTableRecord::emit - fix boolean operator precedence warnings from PVS ↵Simon Pilgrim2019-11-021-2/+2
| | | | | | Studio. NFCI. Make it clear that (Flags & MTRF_????) should resolve to a boolean.
* [GlobalISel] Match table opt: fix a bug in matching num of operandsRoman Tereshin2019-11-011-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | If there is a dag node with a variable number of operands that has at least N operands (for some non-negative N), and multiple patterns with that node with different number of operands, we would drop the number of operands check in patterns with N operands, presumably because it's guaranteed in such case that none of the per-operand checks will access the operand list out-of-bounds. Except semantically the check is about having exactly N operands, not at least N operands, and a backend might rely on it to disambiguate different patterns. In this patch we change the condition on emitting the number of operands check from "the instruction is not guaranteed to have at least as many operands as are checked by the pattern being matched" to "the instruction is not guaranteed to have a specific number of operands". We're relying (still) on the rest of the CodeGenPatterns mechanics to validate that the pattern itself doesn't try to access more operands than there is in the instruction in cases when the instruction does have fixed number of operands, and on the machine verifier to validate at runtime that particular MIs like that satisfy the constraint as well. Reviewers: dsanders, qcolombet Reviewed By: qcolombet Subscribers: arsenm, rovka, Petar.Avramovic, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D69653
* Reapply r372285 "GlobalISel: Don't materialize immarg arguments to intrinsics"Matt Arsenault2019-09-191-1/+26
| | | | | | | | | This reverts r372314, reapplying r372285 and the commits which depend on it (r372286-r372293, and r372296-r372297) This was missing one switch to getTargetConstant in an untested case. llvm-svn: 372338
* Revert r372285 "GlobalISel: Don't materialize immarg arguments to intrinsics"Hans Wennborg2019-09-191-26/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This broke the Chromium build, causing it to fail with e.g. fatal error: error in backend: Cannot select: t362: v4i32 = X86ISD::VSHLI t392, Constant:i8<15> See llvm-commits thread of r372285 for details. This also reverts r372286, r372287, r372288, r372289, r372290, r372291, r372292, r372293, r372296, and r372297, which seemed to depend on the main commit. > Encode them directly as an imm argument to G_INTRINSIC*. > > Since now intrinsics can now define what parameters are required to be > immediates, avoid using registers for them. Intrinsics could > potentially want a constant that isn't a legal register type. Also, > since G_CONSTANT is subject to CSE and legalization, transforms could > potentially obscure the value (and create extra work for the > selector). The register bank of a G_CONSTANT is also meaningful, so > this could throw off future folding and legalization logic for AMDGPU. > > This will be much more convenient to work with than needing to call > getConstantVRegVal and checking if it may have failed for every > constant intrinsic parameter. AMDGPU has quite a lot of intrinsics wth > immarg operands, many of which need inspection during lowering. Having > to find the value in a register is going to add a lot of boilerplate > and waste compile time. > > SelectionDAG has always provided TargetConstant for constants which > should not be legalized or materialized in a register. The distinction > between Constant and TargetConstant was somewhat fuzzy, and there was > no automatic way to force usage of TargetConstant for certain > intrinsic parameters. They were both ultimately ConstantSDNode, and it > was inconsistently used. It was quite easy to mis-select an > instruction requiring an immediate. For SelectionDAG, start emitting > TargetConstant for these arguments, and using timm to match them. > > Most of the work here is to cleanup target handling of constants. Some > targets process intrinsics through intermediate custom nodes, which > need to preserve TargetConstant usage to match the intrinsic > expectation. Pattern inputs now need to distinguish whether a constant > is merely compatible with an operand or whether it is mandatory. > > The GlobalISelEmitter needs to treat timm as a special case of a leaf > node, simlar to MachineBasicBlock operands. This should also enable > handling of patterns for some G_* instructions with immediates, like > G_FENCE or G_EXTRACT. > > This does include a workaround for a crash in GlobalISelEmitter when > ARM tries to uses "imm" in an output with a "timm" pattern source. llvm-svn: 372314
* GlobalISel: Don't materialize immarg arguments to intrinsicsMatt Arsenault2019-09-191-1/+26
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Encode them directly as an imm argument to G_INTRINSIC*. Since now intrinsics can now define what parameters are required to be immediates, avoid using registers for them. Intrinsics could potentially want a constant that isn't a legal register type. Also, since G_CONSTANT is subject to CSE and legalization, transforms could potentially obscure the value (and create extra work for the selector). The register bank of a G_CONSTANT is also meaningful, so this could throw off future folding and legalization logic for AMDGPU. This will be much more convenient to work with than needing to call getConstantVRegVal and checking if it may have failed for every constant intrinsic parameter. AMDGPU has quite a lot of intrinsics wth immarg operands, many of which need inspection during lowering. Having to find the value in a register is going to add a lot of boilerplate and waste compile time. SelectionDAG has always provided TargetConstant for constants which should not be legalized or materialized in a register. The distinction between Constant and TargetConstant was somewhat fuzzy, and there was no automatic way to force usage of TargetConstant for certain intrinsic parameters. They were both ultimately ConstantSDNode, and it was inconsistently used. It was quite easy to mis-select an instruction requiring an immediate. For SelectionDAG, start emitting TargetConstant for these arguments, and using timm to match them. Most of the work here is to cleanup target handling of constants. Some targets process intrinsics through intermediate custom nodes, which need to preserve TargetConstant usage to match the intrinsic expectation. Pattern inputs now need to distinguish whether a constant is merely compatible with an operand or whether it is mandatory. The GlobalISelEmitter needs to treat timm as a special case of a leaf node, simlar to MachineBasicBlock operands. This should also enable handling of patterns for some G_* instructions with immediates, like G_FENCE or G_EXTRACT. This does include a workaround for a crash in GlobalISelEmitter when ARM tries to uses "imm" in an output with a "timm" pattern source. llvm-svn: 372285
* GlobalISel/TableGen: Handle REG_SEQUENCE patternsMatt Arsenault2019-09-101-9/+65
| | | | | | | | The scalar f64 patterns don't work yet because they fail on multiple results from the unused implicit def of scc in the result bit operation. llvm-svn: 371542
* AMDGPU/GlobalISel: Select atomic loadsMatt Arsenault2019-09-091-0/+4
| | | | | | | A new check for an explicitly atomic MMO is needed to avoid incorrectly matching pattern for non-atomic loads llvm-svn: 371418
* GlobalISel: Support physical register inputs in patternsMatt Arsenault2019-09-061-11/+151
| | | | llvm-svn: 371253
* GlobalISel/TableGen: Fix handling of EXTRACT_SUBREG constraintsMatt Arsenault2019-09-061-19/+47
| | | | | | | | | | | | | | | | This was only using the correct register constraints if this was the final result instruction. If the extract was a sub instruction of the result, it would attempt to use GIR_ConstrainSelectedInstOperands on a COPY, which won't work. Move the handling to createAndImportSubInstructionRenderer so it works correctly. I don't fully understand why runOnPattern and createAndImportSubInstructionRenderer both need to handle these special cases, and constrain them with slightly different methods. If I remove the runOnPattern handling, it does break the constraint when the final result instruction is EXTRACT_SUBREG. llvm-svn: 371150
* GlobalISel/TableGen: Don't skip REG_SEQUENCE based on patternsMatt Arsenault2019-09-041-25/+31
| | | | | | | | This partially adds support for patterns with REG_SEQUENCE. The source patterns are now accepted, but the pattern is still rejected due to missing support for the instruction renderer. llvm-svn: 370920
* GlobalISel/TableGen: Handle setcc patternsMatt Arsenault2019-08-291-1/+68
| | | | | | | | | | | This is a special case because one node maps to two different G_ instructions, and the operand order is changed. This mostly enables G_FCMP for AMDPGPU. G_ICMP is still manually selected for now since it has the SALU and VALU complication to deal with. llvm-svn: 370280
* [GlobalISel] Import patterns containing SUBREG_TO_REGJessica Paquette2019-08-281-19/+85
| | | | | | | | | | | | | | | | | | | | | | | Reuse the logic for INSERT_SUBREG to also import SUBREG_TO_REG patterns. - Split `inferSuperRegisterClass` into two functions, one which tries to use an existing TreePatternNode (`inferSuperRegisterClassForNode`), and one that doesn't. SUBREG_TO_REG doesn't have a node to leverage, which is the cause for the split. - Rename GlobalISelEmitterInsertSubreg.td to GlobalISelEmitterSubreg.td and update it. - Update impacted tests in the AArch64 and X86 backends. This is kind of a hit/miss for code size improvements/regressions. E.g. in add-ext.ll, we now get some identity copies. This isn't really anything the importer can handle, since it's caused by a later pass introducing the copy for the sake of correctness. Differential Revision: https://reviews.llvm.org/D66769 llvm-svn: 370254
* Recommit "[GlobalISel] Import patterns containing INSERT_SUBREG"Jessica Paquette2019-08-271-1/+189
| | | | | | | | | | I thought `llvm::sort` was stable for some reason but it's not. Use `llvm::stable_sort` in `CodeGenTarget::getSuperRegForSubReg`. Original patch: https://reviews.llvm.org/D66498 llvm-svn: 370084
* Revert "[GlobalISel] Import patterns containing INSERT_SUBREG"Jessica Paquette2019-08-271-189/+1
| | | | | | | | | | When EXPENSIVE_CHECKS are enabled, GlobalISelEmitterSubreg.td doesn't get stable output. Reverting while I debug it. See: https://reviews.llvm.org/D66498 llvm-svn: 370080
* [GlobalISel] Import patterns containing INSERT_SUBREGJessica Paquette2019-08-261-1/+189
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This teaches the importer to handle INSERT_SUBREG instructions. We were missing patterns involving INSERT_SUBREG in AArch64. It appears in AArch64InstrInfo.td 107 times, and 14 times in AArch64InstrFormats.td. To meaningfully import it, the GlobalISelEmitter needs to know how to infer a super register class for a given register class. This patch introduces the following: - `getSuperRegForSubReg`, a function which finds the largest register class which supports a value type and subregister index - `inferSuperRegisterClass`, a function which finds the appropriate super register class for an INSERT_SUBREG' - `inferRegClassFromPattern`, a function which allows for some trivial lookthrough into instructions - `getRegClassFromLeaf`, a helper function which returns the register class for a leaf `TreePatternNode` - Support for subregister index operands in `importExplicitUseRenderer` It also - Updates tests in each backend which are impacted by the change - Adds GlobalISelEmitterSubreg.td to test that we import and skip the expected patterns As a result of this patch, INSERT_SUBREG patterns in X86 may use the LOW32_ADDR_ACCESS_RBP register class instead of GR32. This is correct, since the register class contains the same registers as GR32 (except with the addition of RBP). So, this also teaches X86 to handle that register class. This is in line with X86ISelLowering, which treats this as a GR class. Differential Revision: https://reviews.llvm.org/D66498 llvm-svn: 369973
* Teach GlobalISelEmitter to treat used iPTRAny operands as pointer operandsJessica Paquette2019-08-201-7/+16
| | | | | | | | | | | | | | Overloaded intrinsics can use iPTRAny in used/input operands. The GlobalISelEmitter doesn't know that these are pointers, so it treats them as scalars. As a result, these intrinsics can't be imported. This teaches the GlobalISelEmitter to recognize these as pointers rather than scalars. Differential Revision: https://reviews.llvm.org/D65756 llvm-svn: 369455
* [llvm] Migrate llvm::make_unique to std::make_uniqueJonas Devlieghere2019-08-151-7/+7
| | | | | | | | Now that we've moved to C++14, we no longer need the llvm::make_unique implementation from STLExtras.h. This patch is a mechanical replacement of (hopefully) all the llvm::make_unique instances across the monorepo. llvm-svn: 369013
* [GlobalISel] Check LLT size matches memory size for non-truncating stores.Amara Emerson2019-08-021-5/+13
| | | | | | | | This was causing a bug where non-truncating stores would be selected instead of truncating ones. Differential Revision: https://reviews.llvm.org/D64845 llvm-svn: 367737
* TableGen: Add MinAlignment predicateMatt Arsenault2019-07-311-0/+46
| | | | | | | | | | AMDGPU uses some custom code predicates for testing alignments. I'm still having trouble comprehending the behavior of predicate bits in the PatFrag hierarchy. Any attempt to abstract these properties unexpectdly fails to apply them. llvm-svn: 367373
* AMDGPU: Avoid emitting "true" predicatesMatt Arsenault2019-07-301-1/+1
| | | | | | | | | | Empty condition strings are considerde always true. This removes a lot of clutter from the generated matcher tables. This shrinks the source size of AMDGPUGenDAGISel.inc from 7.3M to 6.1M. llvm-svn: 367326
* TableGen/GlobalISel: Fix handling of truncstore patternsMatt Arsenault2019-07-151-1/+8
| | | | | | | | | | | | This was failing to import the AMDGPU truncstore patterns. The truncating stores from 32-bit to 8/16 were then somehow being incorrectly selected to a 4-byte store. A separate check is emitted for the LLT size in comparison to the specific memory VT, which looks strange to me but makes sense based on the hierarchy of PatFrags used for the default truncstore PatFrags. llvm-svn: 366129
* TableGen: Add address space to matchersMatt Arsenault2019-07-151-1/+80
| | | | | | | | | | | | | | | | | Currently AMDGPU uses a CodePatPred to check address spaces from the MachineMemOperand. Introduce a new first class property so that the existing patterns can be easily modified to uses the new generated predicate, which will also be handled for GlobalISel. I would prefer these to match against the pointer type of the instruction, but that would be difficult to get working with SelectionDAG compatbility. This is much easier for now and will avoid a painful tablegen rewrite for all the loads and stores. I'm also not sure if there's a better way to encode multiple address spaces in the table, rather than putting the number to expect. llvm-svn: 366128
* Follow up and fix for rL362064Sjoerd Meijer2019-05-311-1/+2
| | | | | | | | Fix the misleadingly indentation introduced in rL362064. This will get rid of the compiler warning, and it was actually a bug. This change will be used and tested in D62669. llvm-svn: 362211
* [TableGen] New default operand "undef_tied_input"Sjoerd Meijer2019-05-301-4/+25
| | | | | | | | | | | | | | | | | | | | | | | | | | This is a new special identifier which you can use as a default in OperandWithDefaultOps. The idea is that you use it for an input operand of an instruction that's tied to an output operand, and its semantics are that (in the default case) the input operand's value is not used at all. The detailed effect is that when instruction selection emits the instruction in the form of a pre-regalloc MachineInstr, it creates an IMPLICIT_DEF node to use as that input. If you're creating an MCInst with explicit register names, then the right handling would be to set the input operand to the same register as the output one (honouring the tie) and to add the 'undef' flag indicating that that register is deemed to acquire a new don't-care definition just before we read it. But I haven't done that in this commit, because there was no need to - no Tablegen backend seems to autogenerate default fields in an MCInst. Patch by: Simon Tatham Differential Revision: https://reviews.llvm.org/D60696 llvm-svn: 362064
* Use llvm::stable_sortFangrui Song2019-04-231-2/+1
| | | | | | While touching the code, simplify if feasible. llvm-svn: 358996
* Add support for pointer types in patternsTom Stellard2019-02-201-0/+3
| | | | | | | | | | | | | | | | | | | | | | | | Summary: This adds support for defining patterns for global isel using pointer types, for example: def : Pat<(load GPR32:$src), (p1 (LOAD GPR32:$src))>; DAGISelEmitter will ignore the pointer information and treat these types as integers with the same bit-width as the pointer type. Reviewers: dsanders, rtereshin, arsenm Reviewed By: arsenm Subscribers: Petar.Avramovic, wdng, rovka, kristof.beyls, jfb, volkan, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D57065 llvm-svn: 354510
* [GlobalISel] Skip patterns that define complex suboperands twice instead of ↵Jessica Paquette2019-02-091-6/+16
| | | | | | | | | | | | | | | | | | | dying If we run into a pattern that looks like this: add (complex $x, $y) (complex $x, $z) We should skip the pattern instead of asserting/doing something unpredictable. This makes us return an Error in that case, and adds a testcase for skipped patterns. Differential Revision: https://reviews.llvm.org/D57980 llvm-svn: 353586
* Update the file headers across all of the LLVM projects in the monorepoChandler Carruth2019-01-191-4/+3
| | | | | | | | | | | | | | | | | to reflect the new license. We understand that people may be surprised that we're moving the header entirely to discuss the new license. We checked this carefully with the Foundation's lawyer and we believe this is the correct approach. Essentially, all code in the project is now made available by the LLVM project under our new license, so you will see that the license headers include that license only. Some of our contributors have contributed code under our old license, and accordingly, we have retained a copy of our old license notice in the top-level files in each project and repository. llvm-svn: 351636
* TableGen/ISel: Allow PatFrag predicate code to access captured operandsNicolai Haehnle2018-11-301-4/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: This simplifies writing predicates for pattern fragments that are automatically re-associated or commuted. For example, a followup patch adds patterns for fragments of the form (add (shl $x, $y), $z) to the AMDGPU backend. Such patterns are automatically commuted to (add $z, (shl $x, $y)), which makes it basically impossible to refer to $x, $y, and $z generically in the PredicateCode. With this change, the PredicateCode can refer to $x, $y, and $z simply as `Operands[i]`. Test confirmed that there are no changes to any of the generated files when building all (non-experimental) targets. Change-Id: I61c00ace7eed42c1d4edc4c5351174b56b77a79c Reviewers: arsenm, rampitec, RKSimon, craig.topper, hfinkel, uweigand Subscribers: wdng, tpr, llvm-commits Differential Revision: https://reviews.llvm.org/D51994 llvm-svn: 347992
* Use the container form llvm::sort(C, ...)Fangrui Song2018-09-301-21/+18
| | | | | | | There are a few leftovers in rL343163 which span two lines. This commit changes these llvm::sort(C.begin(), C.end, ...) to llvm::sort(C, ...) llvm-svn: 343426
* llvm::sort(C.begin(), C.end(), ...) -> llvm::sort(C, ...)Fangrui Song2018-09-271-5/+5
| | | | | | | | | | | | Summary: The convenience wrapper in STLExtras is available since rL342102. Reviewers: dblaikie, javed.absar, JDevlieghere, andreadb Subscribers: MatzeB, sanjoy, arsenm, dschuff, mehdi_amini, sdardis, nemanjai, jvesely, nhaehnle, sbc100, jgravelle-google, eraman, aheejin, kbarton, JDevlieghere, javed.absar, gbedwell, jrtc27, mgrang, atanasyan, steven_wu, george.burgess.iv, dexonsmith, kristina, jsji, llvm-commits Differential Revision: https://reviews.llvm.org/D52573 llvm-svn: 343163
* [globalisel][tblgen] Table optimization should consider the C++ code in C++ ↵Daniel Sanders2018-09-251-0/+6
| | | | | | | | predicates This fixes PR39045 llvm-svn: 342997
* [globalisel] Remove dead code from GlobalISelEmitterDaniel Sanders2018-08-121-17/+0
| | | | | | | | | | | | | | | | Summary: Found by GCC's -Wunused-function. Patch by Kim Gräsman Reviewers: ab, dsanders, llvm-commits Reviewed By: dsanders Subscribers: rovka, kristof.beyls Differential Revision: https://reviews.llvm.org/D50611 llvm-svn: 339528
* [NFC] Prefer (void) to LLVM_ATTRIBUTE_UNUSED for unused var in ↵Andrei Elovikov2018-06-261-2/+2
| | | | | | | | | | | | | | GlobalISElemitter.cpp. Reviewers: dsanders, craig.topper Reviewed By: dsanders Subscribers: rovka, kristof.beyls, llvm-commits Differential Revision: https://reviews.llvm.org/D48534 llvm-svn: 335581
* [globalisel][tablegen] Add support for C++ predicates on PatFrags and use it ↵Daniel Sanders2018-06-151-20/+103
| | | | | | | | | | | | | | | | | | | | | to support BFC on ARM. So far, we've only handled special cases of PatFrag like ImmLeaf. This patch adds support for the remaining cases using similar mechanisms. Like most C++ code from SelectionDAG, GISel and DAGISel expect to operate on different types and representations and as such the code is not compatible between the two. It's therefore necessary to add an alternative implementation in the GISelPredicateCode field. The target test for this feature could easily be done with IntImmLeaf and this would save on a little boilerplate. The reason I've chosen to implement this using PatFrag.GISelPredicateCode and not IntImmLeaf is because I was unable to find a rule that was blocked solely by lack of support for PatFrag predicates. I found that the ones I investigated as being likely candidates for the test were further blocked by other things. llvm-svn: 334871
* Revert r334764, as it breaks some botsFlorian Hahn2018-06-141-105/+106
| | | | llvm-svn: 334767
* [TableGen] Make TreePatternNode::getChild return a reference (NFC)Florian Hahn2018-06-141-106/+105
| | | | | | | | The return value of TreePatternNode::getChild is never null. This patch also updates various places that use return values of getChild to also use references. Those changes were suggested post-commit for D47463. llvm-svn: 334764
* [GlobalISel][InstructionSelect] Switching over root LLTs, perf patch 10Roman Tereshin2018-05-241-1/+10
| | | | | | | | | | | | | | | | | | | | | | | | | This patch continues a series of patches started by r332907 (reapplied as r332917). In this commit we introduce new matching opcode for the MatchTable: GIM_SwitchType, similar to GIM_SwitchOpcode, and use it to switch over LLTs of def operands of root instructions on the 2nd level of the MatchTable within GIM_SwitchOpcode's cases. This is expected to decrease time GlobalISel spends in its InstructionSelect pass by about 6.5% for an -O0 build as measured on sqlite3-amalgamation (http://sqlite.org/download.html) targeting AArch64 (cross-compile on x86). Reviewers: qcolombet, dsanders, bogner, aemerson, javed.absar Reviewed By: qcolombet Subscribers: rovka, llvm-commits, kristof.beyls Differential Revision: https://reviews.llvm.org/D44700 llvm-svn: 333146
* [GlobalISel][InstructionSelect] Moving Reg Bank Checks forward, perf patch 9Roman Tereshin2018-05-231-10/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | This patch continues a series of patches started by r332907 (reapplied as r332917). In this commit we move register bank checks back from epilogue of every rule matcher to a position locally close to the rest of the checks for a particular (nested) instruction. This increases the number of common conditions within 2nd level groups. This is expected to decrease time GlobalISel spends in its InstructionSelect pass by about 2% for an -O0 build as measured on sqlite3-amalgamation (http://sqlite.org/download.html) targeting AArch64 (cross-compile on x86). Reviewers: qcolombet, dsanders, bogner, aemerson, javed.absar Reviewed By: qcolombet Subscribers: rovka, llvm-commits, kristof.beyls Differential Revision: https://reviews.llvm.org/D44700 llvm-svn: 333144
* [GlobalISel][InstructionSelect] Maximizing # of Group's common conditions, ↵Roman Tereshin2018-05-231-3/+13
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | perf patch 8 This patch continues a series of patches started by r332907 (reapplied as r332917). In this commit we greedily stuff 2nd level GroupMatcher's common conditions with as many predicates as possible. This is purely post-processing and it doesn't change which rules are put into the groups in the first place: that decision is made by looking at the first common predicate only. The compile time improvements are minor and well within error margin, however, it's highly improbable that this transformation could pessimize performance, thus I'm still committing it for potential gains for targets not implementing GlobalISel yet and out of tree targets. Reviewers: qcolombet, dsanders, bogner, aemerson, javed.absar Reviewed By: qcolombet Subscribers: rovka, llvm-commits, kristof.beyls Differential Revision: https://reviews.llvm.org/D44700 llvm-svn: 333139
* [GlobalISel][InstructionSelect] Sorting MatchTable's 2nd level by root LLT, ↵Roman Tereshin2018-05-231-0/+32
| | | | | | | | | | | | | | | | | | | | | | | | | | perf patch 7 This patch continues a series of patches started by r332907 (reapplied as r332917). In this commit we sort rules within their 2nd level by the type check on def operand of the root instruction, which allows for better nesting grouping on the level. This is expected to decrease time GlobalISel spends in its InstructionSelect pass by roughly 22% for an -O0 build as measured on sqlite3-amalgamation (http://sqlite.org/download.html) targeting AArch64 (cross-compile on x86). Reviewers: qcolombet, dsanders, bogner, aemerson, javed.absar Reviewed By: qcolombet Subscribers: rovka, llvm-commits, kristof.beyls Differential Revision: https://reviews.llvm.org/D44700 llvm-svn: 333131
* [GlobalISel][InstructionSelect] Moving type checks forward, perf patch 6Roman Tereshin2018-05-231-0/+6
| | | | | | | | | | | | | | | | | | | | | | | | | This patch continues a series of patches started by r332907 (reapplied as r332917) In this commit we sort type checks towards the beginning of every rule within the MatchTable as they fail often and it's best to fail early. This is expected to decrease time GlobalISel spends in its InstructionSelect pass by roughly 7% for an -O0 build as measured on sqlite3-amalgamation (http://sqlite.org/download.html) targeting AArch64. The amalgamation is a large single-file C-source that makes compiler backend performance improvements to stand out from frontend. It's also a part of CTMark. Reviewers: qcolombet, dsanders, bogner, aemerson, javed.absar Reviewed By: qcolombet Subscribers: rovka, llvm-commits, kristof.beyls Differential Revision: https://reviews.llvm.org/D44700 llvm-svn: 333114
* Remove DEBUG macro.Nicola Zaghen2018-05-231-1/+1
| | | | | | | | | | Now that the LLVM_DEBUG() macro landed on the various sub-projects the DEBUG macro can be removed. Also change the new uses of DEBUG to LLVM_DEBUG. Differential Revision: https://reviews.llvm.org/D46952 llvm-svn: 333091
OpenPOWER on IntegriCloud