summaryrefslogtreecommitdiffstats
path: root/llvm/utils/TableGen
Commit message (Collapse)AuthorAgeFilesLines
...
* [DFAPacketizer] Allow up to 64 functional unitsjmolloy2019-11-051-335/+143
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: To drive the automaton we used a uint64_t as an action type. This contained the transition's resource requirements as a conjunction: (a OR b) AND (b OR c) We encoded this conjunction as a sequence of four 16-bit bitmasks. This limited the number of addressable functional units to 16, which is quite low and has bitten many people in the past. Instead, the DFAEmitter now generates a lookup table from InstrItinerary class (index of the ItinData inside the ProcItineraries) to an internal action index which is essentially a dense embedding of the conjunctive form. Because we never materialize the conjunctive form, we no longer have the 16 FU restriction. In this patch we limit to 64 functional units due to using a uint64_t bitmask in the DFAEmitter. Now that we've decoupled these representations we can increase this in future. Reviewers: ThomasRaoux, kparzysz, majnemer Reviewed By: ThomasRaoux Subscribers: hiraditya, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D69110
* Stop static analyzer warnings about using bitwise operators on booleans. NFCI.Simon Pilgrim2019-11-021-6/+6
| | | | Call each of the rebase_if() calls separately.
* 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.
* Revert "[Codegen] Both sides of '&&' are same; fixed"Dávid Bolvanský2019-11-021-1/+1
| | | | This reverts commit edb42dccfafb2c0d25d19175c49d016a7c2e0b13. Buildbot timeouts.
* [Codegen] Both sides of '&&' are same; fixedDávid Bolvanský2019-11-021-1/+1
| | | | | | | | | | | | | | | | | Summary: Found by PVS Studio Not familiar with this code; no testcase. Reviewers: craig.topper, RKSimon Reviewed By: RKSimon Subscribers: llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D69741
* [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
* TableGen: Use enum names in composeSubRegIndices tableMatt Arsenault2019-10-271-1/+1
| | | | | I'm not sure why this is using the raw enum value. This makes reading the generated table comprehensible.
* [gicombiner] Add parse failure tests for defs/matchDaniel Sanders2019-10-251-0/+3
|
* Relax assertions when there's really no entries. [NFC]Michael Liao2019-10-221-2/+2
|
* [DFAPacketizer] Fix large compile-time regression for VLIW targetsJames Molloy2019-10-181-2/+2
| | | | | | | | | | D68992 / rL375086 refactored the packetizer and removed a bunch of logic. Unfortunately it creates an Automaton object whenever a DFAPacketizer is required. These objects have no longevity, and in particular on a debug build the population of the Automaton's transition map from the underlying table is very slow (because it is called ~10 times per MachineFunction, in the testcase I'm looking at). This patch changes Automaton to wrap its underlying constant data in std::shared_ptr, which allows trivial copy construction. The DFAPacketizer creation function now creates a static archetypical Automaton and copies that whenever a new DFAPacketizer is required. This takes a testcase down from ~20s to ~0.5s in debug mode. llvm-svn: 375240
* [DFAPacketizer] Use DFAEmitter. NFC.James Molloy2019-10-171-574/+72
| | | | | | | | | | | | | | | Summary: This is a NFC change that removes the NFA->DFA construction and emission logic from DFAPacketizerEmitter and instead uses the generic DFAEmitter logic. This allows DFAPacketizer to use the Automaton class from Support and remove a bunch of logic there too. After this patch, DFAPacketizer is mostly logic for grepping Itineraries and collecting functional units, with no state machine logic. This will allow us to modernize by removing the 16-functional-unit limit and supporting non-itinerary functional units. This is all for followup patches. Subscribers: hiraditya, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D68992 llvm-svn: 375086
* Correct placement of #ifndef NDEBUG in r375067Daniel Sanders2019-10-171-12/+7
| | | | llvm-svn: 375071
* [gicombiner] Add the run-time rule disable optionDaniel Sanders2019-10-171-3/+97
| | | | | | | | | | | | | | | | | | | | | | | | | Summary: Each generated helper can be configured to generate an option that disables rules in that helper. This can be used to bisect rulesets. The disable bits are stored in a SparseVector as this is very cheap for the common case where nothing is disabled. It gets more expensive the more rules are disabled but you're generally doing that for debug purposes where performance is less of a concern. Depends on D68426 Reviewers: volkan, bogner Reviewed By: volkan Subscribers: hiraditya, Petar.Avramovic, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D68438 llvm-svn: 375067
* [gicombiner] Hoist pure C++ combine into the tablegen definitionDaniel Sanders2019-10-161-6/+264
| | | | | | | | | | | | | | | | | | | | | | Summary: This is just moving the existing C++ code around and will be NFC w.r.t AArch64. Renamed 'CombineBr' to something more descriptive ('ElideByByInvertingCond') at the same time. The remaining combines in AArch64PreLegalizeCombiner require features that aren't implemented at this point and will be hoisted as they are added. Depends on D68424 Reviewers: bogner, volkan Subscribers: kristof.beyls, hiraditya, Petar.Avramovic, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D68426 llvm-svn: 375057
* [TableGen] Fix a bug that MCSchedClassDesc is interfered between different ↵QingShan Zhang2019-10-111-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | SchedModel Assume that, ModelA has scheduling resource for InstA and ModelB has scheduling resource for InstB. This is what the llvm::MCSchedClassDesc looks like: llvm::MCSchedClassDesc ModelASchedClasses[] = { ... InstA, 0, ... InstB, -1,... }; llvm::MCSchedClassDesc ModelBSchedClasses[] = { ... InstA, -1,... InstB, 0,... }; The -1 means invalid num of macro ops, while it is valid if it is >=0. This is what we look like now: llvm::MCSchedClassDesc ModelASchedClasses[] = { ... InstA, 0, ... InstB, 0,... }; llvm::MCSchedClassDesc ModelBSchedClasses[] = { ... InstA, 0,... InstB, 0,... }; And compiler hit the assertion here because the SCDesc is valid now for both InstA and InstB. Differential Revision: https://reviews.llvm.org/D67950 llvm-svn: 374524
* [TableGen] Fix crash when using HwModes in CodeEmitterGenJames Molloy2019-10-091-1/+2
| | | | | | | | When an instruction has an encoding definition for only a subset of the available HwModes, ensure we just avoid generating an encoding rather than crash. llvm-svn: 374150
* [tblgen] Add getOperatorAsDef() to RecordDaniel Sanders2019-10-082-13/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: While working with DagInit's, it's often the case that you expect the operator to be a reference to a def. This patch adds a wrapper for this common case to reduce the amount of boilerplate callers need to duplicate repeatedly. getOperatorAsDef() returns the record if the DagInit has an operator that is a DefInit. Otherwise, it prints a fatal error. There's only a few pre-existing examples in LLVM at the moment and I've left a few instances of the code this simplifies as they had more specific error messages than the generic one this produces. I'm going to be using this a fair bit in my subsequent patches. Reviewers: bogner, volkan, nhaehnle Reviewed By: nhaehnle Subscribers: nhaehnle, hiraditya, asb, rbar, johnrusso, simoncook, apazos, sabuasal, niosHD, jrtc27, MaskRay, zzheng, edward-jones, rogfer01, MartinMosbeck, brucehoult, the_o, PkmX, jocewei, lenary, s.egerton, pzheng, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D68424 llvm-svn: 374101
* GlobalISel: Add target pre-isel instructionsMatt Arsenault2019-10-073-0/+3
| | | | | | | | | | | | | | Allows targets to introduce regbankselectable pseudo-instructions. Currently the closet feature to this is an intrinsic. However this requires creating a public intrinsic declaration. This litters the public intrinsic namespace with operations we don't necessarily want to expose to IR producers, and would rather leave as private to the backend. Use a new instruction bit. A previous attempt tried to keep using enum value ranges, but it turned into a mess. llvm-svn: 373937
* [TableGen] Pacify gcc-5.4 moreJames Molloy2019-10-071-2/+2
| | | | | | | Followup to a previous pacification, this performs the same workaround to the TableGen generated code for tuple automata. llvm-svn: 373883
* [TableGen] Introduce a generic automaton (DFA) backendJames Molloy2019-10-045-1/+510
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: This patch introduces -gen-automata, a backend for generating deterministic finite-state automata. DFAs are already generated by the -gen-dfa-packetizer backend. This backend is more generic and will hopefully be used to implement the DFA generation (and determinization) for the packetizer in the future. This backend allows not only generation of a DFA from an NFA (nondeterministic finite-state automaton), it also emits sidetables that allow a path through the DFA under a sequence of inputs to be analyzed, and the equivalent set of all possible NFA transitions extracted. This allows a user to not just answer "can my problem be solved?" but also "what is the solution?". Clearly this analysis is more expensive than just playing a DFA forwards so is opt-in. The DFAPacketizer has this behaviour already but this is a more compact and generic representation. Examples are bundled in unittests/TableGen/Automata.td. Some are trivial, but the BinPacking example is a stripped-down version of the original target problem I set out to solve, where we pack values (actually immediates) into bins (an immediate pool in a VLIW bundle) subject to a set of esoteric constraints. Reviewers: t.p.northover Subscribers: mgorny, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D67968 llvm-svn: 373718
* [gicombiner] Add a CodeExpander to handle C++ fragments with variable expansionDaniel Sanders2019-10-036-0/+206
| | | | | | | | | | | | | | | | | | | | | | | Summary: This will handle expansion of C++ fragments in the declarative combiner including custom predicates, and escapes into C++ to aid the migration effort. Fixed the -DLLVM_LINK_LLVM_DYLIB=ON using DISABLE_LLVM_LINK_LLVM_DYLIB when creating the library. Apparently it automatically links to libLLVM.dylib and we don't want that from tablegen. Reviewers: bogner, volkan Subscribers: mgorny, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D68288 > llvm-svn: 373551 llvm-svn: 373651
* Revert 373551 (CodeExpander.cpp CMake issue)Kristina Brooks2019-10-036-206/+0
| | | | | | | | Fix buildbots and revert the CodeExpander commit. (See http://lists.llvm.org/pipermail/llvm-commits/Week-of-Mon-20190930/699857.html ) llvm-svn: 373581
* Revert 373555: libLLVM+modules failure with CMake 3.10.2Kristina Brooks2019-10-032-2/+2
| | | | | | | | | This reverts rL373555. I've sent an email out regarding the issue. Commit on GitHub: https://github.com/llvm/llvm-project/commit/45f682f47129c05414d4c5ae7be851772273978f llvm-svn: 373579
* [gicombiner] Make rL373551 compatible with older cmakesDaniel Sanders2019-10-032-2/+2
| | | | | | | Newer cmakes appear to be more flexible w.r.t object libraries. Convert to a static library so that it works with older cmakes too llvm-svn: 373555
* [gicombiner] Add a CodeExpander to handle C++ fragments with variable expansionDaniel Sanders2019-10-036-0/+206
| | | | | | | | | | | | | | | | | Summary: This will handle expansion of C++ fragments in the declarative combiner including custom predicates, and escapes into C++ to aid the migration effort. Reviewers: bogner, volkan Subscribers: mgorny, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D68288 llvm-svn: 373551
* [gicombiner] Fix a nullptr dereference when -combiners is given a name that ↵Daniel Sanders2019-10-021-5/+11
| | | | | | | | | isn't defined This is unlikely to be the root cause for the windows bot failures but it would explain the stack trace seen. llvm-svn: 373543
* [gicombiner] Add the boring boilerplate for the declarative combinerDaniel Sanders2019-10-024-0/+102
| | | | | | | | | | | | | | | | | | | | | | | | | | Summary: This is the first of a series of patches extracted from a much bigger WIP patch. It merely establishes the tblgen pass and the way empty combiner helpers are declared and integrated into a combiner info. The tablegen pass takes a -combiners option to select the combiner helper that will be generated. This can be given multiple values to generate multiple combiner helpers at once. Doing so helps to minimize parsing overhead. The reason for creating a GlobalISel subdirectory in utils/TableGen is that there will be quite a lot of non-pass files (~15) by the time the patch series is done. Reviewers: volkan Subscribers: mgorny, hiraditya, simoncook, Petar.Avramovic, s.egerton, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D68286 llvm-svn: 373527
* Fix inconsistent indentation in TableGen.cppDaniel Sanders2019-10-021-68/+64
| | | | | | | The anonymous namespace starts out (incorrectly) indented but isn't indented from the TimeRegionsOpt declaration onwards. llvm-svn: 373516
* [TableGen] Improve error reporting of overlapping definitions (NFC)Evandro Menezes2019-10-021-6/+14
| | | | llvm-svn: 373514
* [IntrinsicEmitter] Add overloaded type VecOfBitcastsToInt for SVE intrinsicsKerry McLaughlin2019-10-021-1/+4
| | | | | | | | | | | | | | | | | | | | | Summary: This allows intrinsics such as the following to be defined: - declare <n x 4 x i32> @llvm.something.nxv4f32(<n x 4 x i32>, <n x 4 x i1>, <n x 4 x float>) ...where <n x 4 x i32> is derived from <n x 4 x float>, but the element needs bitcasting to int. Reviewers: c-rhodes, sdesmalen, rovka Reviewed By: c-rhodes Subscribers: tschuett, hiraditya, jdoerfert, llvm-commits, cfe-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D68021 llvm-svn: 373437
* [X86] Consider isCodeGenOnly in the EVEX2VEX pass to make VMAXPD/PS map to ↵Craig Topper2019-10-011-0/+1
| | | | | | | | | | the non-commutable VEX instruction. Use EVEX2VEX override to fix the scalar instructions. Previously the match was ambiguous and VMAXPS/PD and VMAXCPS/PD were mapped to the same VEX instruction. But we should keep the commutableness when change the opcode. llvm-svn: 373303
* DAGISelMatcherOpt - TGParser::ParseOperation - silence static analyzer ↵Simon Pilgrim2019-09-261-4/+5
| | | | | | | | cast_or_null<CheckTypeMatcher> null dereference warning. NFCI. The static analyzer is warning about a potential null dereference, replace with an null/isa assertion and cast<CheckTypeMatcher>. llvm-svn: 373001
* [tblgen] Disable Leak detection for ASan/GCC and LSan/LLVMKamil Rytarowski2019-09-241-4/+9
| | | | | | | | | | | | | | | | Summary: Add support for sanitizing TableGen.cpp with ASan/GCC and LSan/LLVM. Reviewers: fjricci, kcc, aaron.ballman, mgorny Reviewed By: fjricci Subscribers: jakubjelinek, llvm-commits, #llvm Tags: #llvm Differential Revision: https://reviews.llvm.org/D67908 llvm-svn: 372731
* [TableGen] Emit OperandType enums for RegisterOperands/RegisterClassesAditya Nandakumar2019-09-231-7/+18
| | | | | | | | | | | | | | https://reviews.llvm.org/D66773 The OpTypes::OperandType was creating an enum for all records that inherit from Operand, but in reality there are operands for instructions that inherit from other types too. In particular, RegisterOperand and RegisterClass. This commit adds those types to the list of operand types that are tracked by the OperandType enum. Patch by: nlguillemot llvm-svn: 372641
* Cosmetic; don't use the magic constant 35 when HASH is more readable. This ↵Mark Murray2019-09-231-0/+1
| | | | | | | | | | | | | | | | matches other MCK__<THING>_* usage better. Summary: No functional change. This fixes a magic constant in MCK__*_... macros only. Reviewers: ostannard Subscribers: hiraditya, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D67840 llvm-svn: 372599
* [X86][TableGen] Allow timm to appear in output patterns. Use it to remove ↵Craig Topper2019-09-221-0/+1
| | | | | | | | | | | | | | ConvertToTarget opcodes from the X86 isel table. We're now using a lot more TargetConstant nodes in SelectionDAG. But we were still telling isel to convert some of them to TargetConstants even though they already are. This is because isel emits a conversion anytime the output pattern has a an 'imm'. I guess for patterns in instructions we take the 'timm' from the 'set' pattern, but for Pat patterns with explcicit output we previously had to say 'imm' since 'timm' wasn't allowed in outputs. llvm-svn: 372525
* [IntrinsicEmitter] Add overloaded types for SVE intrinsics (Subdivide2 & ↵Kerry McLaughlin2019-09-201-1/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | Subdivide4) Summary: Both match the type of another intrinsic parameter of a vector type, but where each element is subdivided to form a vector with more elements of a smaller type. Subdivide2Argument allows intrinsics such as the following to be defined: - declare <vscale x 4 x i32> @llvm.something.nxv4i32(<vscale x 8 x i16>) Subdivide4Argument allows intrinsics such as: - declare <vscale x 4 x i32> @llvm.something.nxv4i32(<vscale x 16 x i8>) Tests are included in follow up patches which add intrinsics using these types. Reviewers: sdesmalen, SjoerdMeijer, greened, rovka Reviewed By: sdesmalen Subscribers: rovka, tschuett, jdoerfert, cfe-commits, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D67549 llvm-svn: 372380
* 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
* [TableGen] Support encoding per-HwModeJames Molloy2019-09-196-38/+179
| | | | | | | | | | | | | | Much like ValueTypeByHwMode/RegInfoByHwMode, this patch allows targets to modify an instruction's encoding based on HwMode. When the EncodingInfos field is non-empty the Inst and Size fields of the Instruction are ignored and taken from EncodingInfos instead. As part of this promote getHwMode() from TargetSubtargetInfo to MCSubtargetInfo. This is NFC for all existing targets - new code is generated only if targets use EncodingByHwMode. llvm-svn: 372320
* 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
* Fix compile-time regression caused by rL371928Daniel Sanders2019-09-181-30/+40
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: Also fixup rL371928 for cases that occur on our out-of-tree backend There were still quite a few intermediate APInts and this caused the compile time of MCCodeEmitter for our target to jump from 16s up to ~5m40s. This patch, brings it back down to ~17s by eliminating pretty much all of them using two new APInt functions (extractBitsAsZExtValue(), insertBits() but with a uint64_t). The exact conditions for eliminating them is that the field extracted/inserted must be <=64-bit which is almost always true. Note: The two new APInt API's assume that APInt::WordSize is at least 64-bit because that means they touch at most 2 APInt words. They statically assert that's true. It seems very unlikely that someone is patching it to be smaller so this should be fine. Reviewers: jmolloy Reviewed By: jmolloy Subscribers: hiraditya, dexonsmith, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D67686 llvm-svn: 372243
* [TableGen] CodeGenMapTable - Don't dereference a dyn_cast result. NFCI.Simon Pilgrim2019-09-171-2/+2
| | | | | | The static analyzer is warning about potential null dereferences of dyn_cast<> results - in these cases we can safely use cast<> directly as we know that these cases should all be the correct type, which is why its working atm and anyway cast<> will assert if they aren't. llvm-svn: 372146
* [SVE][MVT] Fixed-length vector MVT rangesGraham Hunter2019-09-171-2/+8
| | | | | | | | | | | | | | | | | * Reordered MVT simple types to group scalable vector types together. * New range functions in MachineValueType.h to only iterate over the fixed-length int/fp vector types. * Stopped backends which don't support scalable vector types from iterating over scalable types. Reviewers: sdesmalen, greened Reviewed By: greened Differential Revision: https://reviews.llvm.org/D66339 llvm-svn: 372099
* [CodeEmitter] Support instruction widths > 64 bitsJames Molloy2019-09-151-37/+151
| | | | | | | | | | | | | | | | | | | | | | | | | | Some VLIW instruction sets are Very Long Indeed. Using uint64_t constricts the Inst encoding to 64 bits (naturally). This change switches CodeEmitter to a mode that uses APInts when Inst's bitwidth is > 64 bits (NFC for existing targets). When Inst.BitWidth > 64 the prototype changes to: void TargetMCCodeEmitter::getBinaryCodeForInstr(const MCInst &MI, SmallVectorImpl<MCFixup> &Fixups, APInt &Inst, APInt &Scratch, const MCSubtargetInfo &STI); The Inst parameter returns the encoded instruction, the Scratch parameter is used internally for manipulating operands and is exposed so that the underlying storage can be reused between calls to getBinaryCodeForInstr. The goal is to elide any APInt constructions that we can. Similarly the operand encoding prototype changes to: getMachineOpValue(const MCInst &MI, const MCOperand &MO, APInt &op, SmallVectorImpl<MCFixup> &Fixups, const MCSubtargetInfo &STI); That is, the operand is passed by reference as APInt rather than returned as uint64_t. To reiterate, this APInt mode is enabled only when Inst.BitWidth > 64, so this change is NFC for existing targets. llvm-svn: 371928
* AArch64: support arm64_32, an ILP32 slice for watchOS.Tim Northover2019-09-121-0/+4
| | | | | | | | This is the main CodeGen patch to support the arm64_32 watchOS ABI in LLVM. FastISel is mostly disabled for now since it would generate incorrect code for ILP32. llvm-svn: 371722
* 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
* AMDGPU: Remove code address space predicatesMatt Arsenault2019-09-091-0/+1
| | | | | | | Fixes 8-byte, 8-byte aligned LDS loads. 16-byte case still broken due to not be reported as legal. llvm-svn: 371413
* [DFAPacketizer] Reapply: Track resources for packetized instructionsJames Molloy2019-09-091-48/+92
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Reapply with fix to reduce resources required by the compiler - use unsigned[2] instead of std::pair. This causes clang and gcc to compile the generated file multiple times faster, and hopefully will reduce the resource requirements on Visual Studio also. This fix is a little ugly but it's clearly the same issue the previous author of DFAPacketizer faced (the previous tables use unsigned[2] rather uglily too). This patch allows the DFAPacketizer to be queried after a packet is formed to work out which resources were allocated to the packetized instructions. This is particularly important for targets that do their own bundle packing - it's not sufficient to know simply that instructions can share a packet; which slots are used is also required for encoding. This extends the emitter to emit a side-table containing resource usage diffs for each state transition. The packetizer maintains a set of all possible resource states in its current state. After packetization is complete, all remaining resource states are possible packetization strategies. The sidetable is only ~500K for Hexagon, but the extra tracking is disabled by default (most uses of the packetizer like MachinePipeliner don't care and don't need the extra maintained state). Differential Revision: https://reviews.llvm.org/D66936 llvm-svn: 371399
OpenPOWER on IntegriCloud