summaryrefslogtreecommitdiffstats
path: root/llvm/utils/TableGen
Commit message (Collapse)AuthorAgeFilesLines
...
* [X86] Make the X86FoldTablesEmitter functional again. Fix the spacing in the ↵Craig Topper2019-06-011-24/+37
| | | | | | | | | output to make it easier to diff. Fix a few other formatting issues in the manual table. And remove some old FIXMEs. llvm-svn: 362287
* 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
* [X86] Add VP2INTERSECT instructionsPengfei Wang2019-05-311-0/+20
| | | | | | | | | | Support Intel AVX512 VP2INTERSECT instructions in llvm Patch by Xiang Zhang (xiangzhangllvm) Differential Revision: https://reviews.llvm.org/D62366 llvm-svn: 362188
* [TableGen] AsmMatcher: allow repeated input operandsSjoerd Meijer2019-05-301-3/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | If an assembly instruction has to mention an input operand name twice, for example the MVE VMOV instruction that accesses two lanes of the same vector by writing 'vmov r1, r2, q0[3], q0[1]', then the obvious way to write its AsmString is to include the same operand (here $Qd) twice. But this causes the AsmMatcher generator to omit that instruction completely from the match table, on the basis that the generator isn't clever enough to deal with the duplication. But you need to have _some_ way of dealing with an instruction like this - and in this case, where the mnemonic is shared with many other instructions that the AsmMatcher does handle, it would be very painful to take it out of the AsmMatcher system completely. A nicer way is to add a custom AsmMatchConverter routine, and let that deal with the problem if the autogenerated converter can't. But that doesn't work, because TableGen leaves the instruction out of its table _even_ if you provide a custom converter. Solution: this change, which makes TableGen relax the restriction on duplicated operands in the case where there's a custom converter. Patch by: Simon Tatham Differential Revision: https://reviews.llvm.org/D60695 llvm-svn: 362066
* [TableGen] New default operand "undef_tied_input"Sjoerd Meijer2019-05-303-5/+37
| | | | | | | | | | | | | | | | | | | | | | | | | | 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
* [TableGen] - Type comparison LE should be LT or equal.Pete Couperus2019-05-201-11/+3
| | | | | | Differential Revision: https://reviews.llvm.org/D61705 llvm-svn: 361183
* [AMDGPU] gfx1010 SearchableTableEmitter patch for NSAStanislav Mekhanoshin2019-05-131-1/+1
| | | | | | | | This part was accidentally missing from NSA image support commit. Differential Revision: https://reviews.llvm.org/D61868 llvm-svn: 360623
* Revert "[TableGen] Fix a typo"Krasimir Georgiev2019-05-071-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | Summary: This reverts commit r360106. The revisioin causes llvm-tblgen to hang while generating info for RISCV.td. The root cause might be in the RISCV.td definition but I don't know enough about this to investigate further. Command that starts hangning after r360106: `llvm-build/bin/llvm-tblgen -I llvm/include -I llvm/tools/clang/include -I llvm/lib/Target/RISCV -gen-instr-info llvm/lib/Target/RISCV/RISCV.td` Reviewers: sammccall, yan_luo, craig.topper, gribozavr Reviewed By: gribozavr Subscribers: PkmX, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D61632 llvm-svn: 360136
* [TableGen] Fix a typoYan Luo2019-05-071-1/+1
| | | | | | | | Check "Big" instead of "Small" in the second condition. Differential Revision: https://reviews.llvm.org/D61605 llvm-svn: 360106
* [TableGen] Fix null pointer dereferencing.Simon Pilgrim2019-04-291-1/+1
| | | | | | Reported in https://www.viva64.com/en/b/0629/ llvm-svn: 359474
* Use llvm::stable_sortFangrui Song2019-04-234-17/+15
| | | | | | While touching the code, simplify if feasible. llvm-svn: 358996
* [TableGen] Include schedule model name in diagnostic.Simon Tatham2019-04-151-1/+2
| | | | | | | | | | | | | | | | | | | | | | | | If you have more than one schedule model in your TableGen target definitions, then the diagnostic "No schedule information for instruction 'foo'" is rather unhelpful, because it doesn't tell you _which_ schedule model is missing the necessary information (or, as it might be, missing the UnsupportedFeatures definition that would stop it thinking it needed it). Extended the message to include the name of the schedule model that it's complaining about. Reviewers: nhaehnle, hfinkel, javedabsar, efriedma, javed.absar Reviewed By: javed.absar Subscribers: javed.absar, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D60559 llvm-svn: 358389
* [X86] Remove check on isAsmParserOnly from EVEX2VEX tablegenerator. NFCICraig Topper2019-04-091-3/+1
| | | | | | There are no instructions VEX or EVEX instructions that set this field. llvm-svn: 357973
* [X86] Have EVEX2VEX tablegenerator use HasVEX_L and HasEVEX_L2 fields ↵Craig Topper2019-04-091-32/+8
| | | | | | | | | | instead of the composite EVEX_LL field. Remove the EVEX_LL field. NFCI The composite existed to simplify some other tablegen code and not really in an important way. Remove the combined field and just calculate the vector size using two ifs. llvm-svn: 357972
* [X86] Use VEX_WIG for VPINSRB/W and VPEXTRB/W to match what is done for EVEX.Craig Topper2019-04-091-1/+1
| | | | | | | | | | | | | The instruction's document this as W0 for the VEX encoding. But there's a footnote mentioning that VEX.W is ignored in 64-bit mode. And the main VEX encoding description says the VEX.W bit is ignored for instructions that are equivalent to a legacy SSE instruction that uses REX.W to select a GPR which would apply here. By making this match EVEX we can remove a special case of allowing EVEX2VEX to turn an EVEX.WIG instruction into VEX.W0. llvm-svn: 357971
* [X86] Split the VEX_WPrefix in X86Inst tablegen class into 3 separate fields ↵Craig Topper2019-04-093-32/+23
| | | | | | with clear meanings. llvm-svn: 357970
* [X86] Merge the different Jcc instructions for each condition code into ↵Craig Topper2019-04-052-1/+10
| | | | | | | | | | | | | | | | | | | | | single instructions that store the condition code as an operand. Summary: This avoids needing an isel pattern for each condition code. And it removes translation switches for converting between Jcc instructions and condition codes. Now the printer, encoder and disassembler take care of converting the immediate. We use InstAliases to handle the assembly matching. But we print using the asm string in the instruction definition. The instruction itself is marked IsCodeGenOnly=1 to hide it from the assembly parser. Reviewers: spatel, lebedev.ri, courbet, gchatelet, RKSimon Reviewed By: RKSimon Subscribers: MatzeB, qcolombet, eraman, hiraditya, arphaman, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D60228 llvm-svn: 357802
* [X86] Merge the different SETcc instructions for each condition code into ↵Craig Topper2019-04-052-3/+18
| | | | | | | | | | | | | | | | | | | | | single instructions that store the condition code as an operand. Summary: This avoids needing an isel pattern for each condition code. And it removes translation switches for converting between SETcc instructions and condition codes. Now the printer, encoder and disassembler take care of converting the immediate. We use InstAliases to handle the assembly matching. But we print using the asm string in the instruction definition. The instruction itself is marked IsCodeGenOnly=1 to hide it from the assembly parser. Reviewers: andreadb, courbet, RKSimon, spatel, lebedev.ri Reviewed By: andreadb Subscribers: hiraditya, lebedev.ri, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D60138 llvm-svn: 357801
* [X86] Merge the different CMOV instructions for each condition code into ↵Craig Topper2019-04-052-5/+25
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | single instructions that store the condition code as an immediate. Summary: Reorder the condition code enum to match their encodings. Move it to MC layer so it can be used by the scheduler models. This avoids needing an isel pattern for each condition code. And it removes translation switches for converting between CMOV instructions and condition codes. Now the printer, encoder and disassembler take care of converting the immediate. We use InstAliases to handle the assembly matching. But we print using the asm string in the instruction definition. The instruction itself is marked IsCodeGenOnly=1 to hide it from the assembly parser. This does complicate the scheduler models a little since we can't assign the A and BE instructions to a separate class now. I plan to make similar changes for SETcc and Jcc. Reviewers: RKSimon, spatel, lebedev.ri, andreadb, courbet Reviewed By: RKSimon Subscribers: gchatelet, hiraditya, kristina, lebedev.ri, jdoerfert, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D60041 llvm-svn: 357800
* [TableGen] Properly calculate the minimum size needed or ConvertFn in ↵Craig Topper2019-04-021-7/+11
| | | | | | | | | | GenAsmmatcher.inc files We were using the number of Matchables rather than the number of rows in the converter table. This only matters for a few of the targets where the number of matchables is more than 255, but the number of converters is less than 255. Many of the targets have more than 256 converters. So already required a uint16_t. llvm-svn: 357527
* fix typo: "\t" => " "Liang Zou2019-03-311-1/+1
| | | | | | | | | | | | | | Reviewers: llvm.org, Jim Reviewed By: Jim Subscribers: arsenm, jvesely, nhaehnle, rupprecht, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D59983 llvm-svn: 357365
* [WebAssembly] Merge used feature sets, update atomics linkage policyThomas Lively2019-03-291-1/+4
| | | | | | | | | | | | | | | | | | | | | | | | | Summary: It does not currently make sense to use WebAssembly features in some functions but not others, so this CL adds an IR pass that takes the union of all used feature sets and applies it to each function in the module. This allows us to prevent atomics from being lowered away if some function has opted in to using them. When atomics is not enabled anywhere, we detect whether there exists any atomic operations or thread local storage that would be stripped and disallow linking with objects that contain atomics if and only if atomics or tls are stripped. When atomics is enabled, mark it as used but do not require it of other objects in the link. These changes allow libraries that do not use atomics to be built once and linked into both single-threaded and multithreaded binaries. Reviewers: aheejin, sbc100, dschuff Subscribers: jgravelle-google, hiraditya, sunfish, jfb, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D59625 llvm-svn: 357226
* [X86] Allow any 8-bit immediate to be used with BT/BTC/BTR/BTS not just sign ↵Craig Topper2019-03-181-0/+6
| | | | | | | | extended 8-bit immediates. We need to allow [128,255] in addition to [-128, 127] to match gas. llvm-svn: 356413
* [X86] Remove the _alt forms of (V)CMP instructions. Use a combination of ↵Craig Topper2019-03-181-4/+0
| | | | | | | | | | custom printing and custom parsing to achieve the same result and more Similar to previous change done for VPCOM and VPCMP Differential Revision: https://reviews.llvm.org/D59468 llvm-svn: 356384
* [X86] Add ADD8ri_DB and ADD8rr_DB to the autogenerated load folding table.Craig Topper2019-03-181-0/+3
| | | | | | | | | These were added in r355423. We only use the autogenerated table to assist with the maintenance of the manual table. These entries are alreayd in the manual table. llvm-svn: 356357
* [CodeGen] Defined MVTs v3i32, v3f32, v5i32, v5f32Tim Renouf2019-03-171-0/+4
| | | | | | | | | AMDGPU would like to use these MVTs. Differential Revision: https://reviews.llvm.org/D58901 Change-Id: I6125fea810d7cc62a4b4de3d9904255a1233ae4e llvm-svn: 356351
* [X86] Remove the _alt forms of AVX512 VPCMP instructions. Use a combination ↵Craig Topper2019-03-171-2/+0
| | | | | | | | | | of custom printing and custom parsing to achieve the same result and more Similar to the previous patch for VPCOM. Differential Revision: https://reviews.llvm.org/D59398 llvm-svn: 356344
* [X86] Remove the _alt forms of XOP VPCOM instructions. Use a combination of ↵Craig Topper2019-03-171-2/+0
| | | | | | | | | | | | | | | | | | | | custom printing and custom parsing to achieve the same result and more Previously we had a regular form of the instruction used when the immediate was 0-7. And _alt form that allowed the full 8 bit immediate. Codegen would always use the 0-7 form since the immediate was always checked to be in range. Assembly parsing would use the 0-7 form when a mnemonic like vpcomtrueb was used. If the immediate was specified directly the _alt form was used. The disassembler would prefer to use the 0-7 form instruction when the immediate was in range and the _alt form otherwise. This way disassembly would print the most readable form when possible. The assembly parsing for things like vpcomtrueb relied on splitting the mnemonic into 3 pieces. A "vpcom" prefix, an immediate representing the "true", and a suffix of "b". The tablegenerated printing code would similarly print a "vpcom" prefix, decode the immediate into a string, and then print "b". The _alt form on the other hand parsed and printed like any other instruction with no specialness. With this patch we drop to one form and solve the disassembly printing issue by doing custom printing when the immediate is 0-7. The parsing code has been tweaked to turn "vpcomtrueb" into "vpcomb" and then the immediate for the "true" is inserted either before or after the other operands depending on at&t or intel syntax. I'd rather not do the custom printing, but I tried using an InstAlias for each possible mnemonic for all 8 immediates for all 16 combinations of element size, signedness, and memory/register. The code emitted into printAliasInstr ended up checking the number of operands, the register class of each operand, and the immediate for all 256 aliases. This was repeated for both the at&t and intel printer. Despite a lot of common checks between all of the aliases, when compiled with clang at least this commonality was not well optimized. Nor do all the checks seem necessary. Since I want to do a similar thing for vcmpps/pd/ss/sd which have 32 immediate values and 3 encoding flavors, 3 register sizes, etc. This didn't seem to scale well for clang binary size. So custom printing seemed a better trade off. I also considered just using the InstAlias for the matching and not the printing. But that seemed like it would add a lot of extra rows to the matcher table. Especially given that the 32 immediates for vpcmpps have 46 strings associated with them. Differential Revision: https://reviews.llvm.org/D59398 llvm-svn: 356343
* IR: Add immarg attributeMatt Arsenault2019-03-123-2/+18
| | | | | | | | | | | | | | | | | This indicates an intrinsic parameter is required to be a constant, and should not be replaced with a non-constant value. Add the attribute to all AMDGPU and generic intrinsics that comments indicate it should apply to. I scanned other target intrinsics, but I don't see any obvious comments indicating which arguments are intended to be only immediates. This breaks one questionable testcase for the autoupgrade. I'm unclear on whether the autoupgrade is supposed to really handle declarations which were never valid. The verifier fails because the attributes now refer to a parameter past the end of the argument list. llvm-svn: 355981
* Use bitset for assembler predicatesStanislav Mekhanoshin2019-03-114-99/+227
| | | | | | | | | | | | | | AMDGPU target run out of Subtarget feature flags hitting the limit of 64. AssemblerPredicates uses at most uint64_t for their representation. At the same time CodeGen has exhausted this a long time ago and switched to a FeatureBitset with the current limit of 192 bits. This patch completes transition to the bitset for feature bits extending it to asm matcher and MC code emitter. Differential Revision: https://reviews.llvm.org/D59002 llvm-svn: 355839
* [TableGen] Replace a dyn_cast with isa to avoid an unused variable warning ↵Craig Topper2019-03-111-6/+2
| | | | | | introduced in r355785. NFC llvm-svn: 355837
* [TableGen] Make CheckImmAllOnesVMatcher and CheckImmAllZerosVMatcher ↵Craig Topper2019-03-102-0/+15
| | | | | | | | contradictory matchers. This improves X86 factoring a little bit. llvm-svn: 355785
* Recommit r355224 "[TableGen][SelectionDAG][X86] Add specific isel matchers ↵Craig Topper2019-03-105-1/+90
| | | | | | | | | | | | | | | | | | for immAllZerosV/immAllOnesV. Remove bitcasts from X86 patterns that are no longer necessary." Includes a fix to emit a CheckOpcode for build_vector when immAllZerosV/immAllOnesV is used as a pattern root. This means it can't be used to look through bitcasts when used as a root, but that's probably ok. This extra CheckOpcode will ensure that the first match in the isel table will be a SwitchOpcode which is needed by the caching optimization in the ISel Matcher. Original commit message: Previously we had build_vector PatFrags that called ISD::isBuildVectorAllZeros/Ones. Internally the ISD::isBuildVectorAllZeros/Ones look through bitcasts, but we aren't able to take advantage of that in isel. Instead of we have to canonicalize the types of the all zeros/ones build_vectors and insert bitcasts. Then we have to pattern match those exact bitcasts. By emitting specific matchers for these 2 nodes, we can make isel look through any bitcasts without needing to explicitly match them. We should also be able to remove the canonicalization to vXi32 from lowering, but I've left that for a follow up. This removes something like 40,000 bytes from the X86 isel table. Differential Revision: https://reviews.llvm.org/D58595 llvm-svn: 355784
* Revert r355224 "[TableGen][SelectionDAG][X86] Add specific isel matchers for ↵Craig Topper2019-03-055-74/+1
| | | | | | | | immAllZerosV/immAllOnesV. Remove bitcasts from X86 patterns that are no longer necessary." This caused the first matcher in the isel table for many targets to Opc_Scope instead of Opc_SwitchOpcode. This leads to a significant increase in isel match failures. llvm-svn: 355433
* [Subtarget] Merge ProcSched and ProcDesc arrays in MCSubtargetInfo into a ↵Craig Topper2019-03-051-42/+11
| | | | | | | | | | | | single array. These arrays are both keyed by CPU name and go into the same tablegenerated file. Merge them so we only need to store keys once. This also removes a weird space saving quirk where we used the ProcDesc.size() to create to build an ArrayRef for ProcSched. Differential Revision: https://reviews.llvm.org/D58939 llvm-svn: 355431
* [Subtarget] Create a separate SubtargetSubtargetKV struct for ProcDesc to ↵Craig Topper2019-03-051-6/+4
| | | | | | | | | | | | remove fields from the stack tables that aren't needed for CPUs The description for CPUs was just the CPU name wrapped with "Select the " and " processor". We can just do that directly in the help printer instead of making a separate version in the binary for each CPU. Also remove the Value field that isn't needed and was always 0. Differential Revision: https://reviews.llvm.org/D58938 llvm-svn: 355429
* [Subtarget] Follow up to r355167, add another set of curly braces to ↵Craig Topper2019-03-041-2/+2
| | | | | | | | FeatureBitArray initialization to satisfy older versions of clang. Apparently older versions of clang like 3.6 require an extra set of curly braces around std::array initializations. I'm told the C++ language was changed regarding this by CWG 1270. llvm-svn: 355327
* [TableGen][SelectionDAG][X86] Add specific isel matchers for ↵Craig Topper2019-03-015-1/+74
| | | | | | | | | | | | | | immAllZerosV/immAllOnesV. Remove bitcasts from X86 patterns that are no longer necessary. Previously we had build_vector PatFrags that called ISD::isBuildVectorAllZeros/Ones. Internally the ISD::isBuildVectorAllZeros/Ones look through bitcasts, but we aren't able to take advantage of that in isel. Instead of we have to canonicalize the types of the all zeros/ones build_vectors and insert bitcasts. Then we have to pattern match those exact bitcasts. By emitting specific matchers for these 2 nodes, we can make isel look through any bitcasts without needing to explicitly match them. We should also be able to remove the canonicalization to vXi32 from lowering, but I've left that for a follow up. This removes something like 40,000 bytes from the X86 isel table. Differential Revision: https://reviews.llvm.org/D58595 llvm-svn: 355224
* [Subtarget] Remove static global constructor call from the tablegened ↵Craig Topper2019-03-011-21/+44
| | | | | | | | | | | | | | | | | | subtarget feature tables Subtarget features are stored in a std::bitset that has been subclassed. There is a special constructor to allow the tablegen files to provide a list of bits to initialize the std::bitset to. This constructor isn't constexpr and std::bitset doesn't support many constexpr operations either. This results in a static global constructor being used to initialize the feature bitsets in these files at startup. To fix this I've introduced a new FeatureBitArray class that holds three 64-bit values representing the initial bit values and taught tablegen to emit hex constants for them based on the feature enum values. This makes the tablegen files less readable than they were before. I can add the list of features back as a comment if we think that's important. I've added a method to convert from this class into the std::bitset subclass we had before. I considered making the new FeatureBitArray class just implement the std::bitset interface we need instead, but thought I'd see how others felts about that first. I've simplified the interfaces to SetImpliedBits and ClearImpliedBits a little minimize the number of times we need to convert to the bitset. This removes about 27K from my local release+asserts build of llc. Differential Revision: https://reviews.llvm.org/D58520 llvm-svn: 355167
* [TableGen] Make OpcodeMappings sort comparator deterministic NFCIAndrew Ng2019-02-261-18/+16
| | | | | | | | | | The previous sort comparator was not deterministic, i.e. in some situations it would be possible for lhs < rhs && rhs < lhs. This was discovered by an STL assertion in a Windows debug build of llvm-tblgen. Differential Revision: https://reviews.llvm.org/D58687 llvm-svn: 354910
* [llvm-objdump] Implement -Mreg-names-raw/-std options.Igor Kudrin2019-02-261-5/+14
| | | | | | | | | | | | | | The --disassembler-options, or -M, are used to customize the disassembler and affect its output. The two implemented options allow selecting register names on ARM: * With -Mreg-names-raw, the disassembler uses rNN for all registers. * With -Mreg-names-std it prints sp, lr and pc for r13, r14 and r15, which is the default behavior of llvm-objdump. Differential Revision: https://reviews.llvm.org/D57680 llvm-svn: 354870
* [ARM] Make fullfp16 instructions not conditionalisable.Simon Tatham2019-02-251-1/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | More or less all the instructions defined in the v8.2a full-fp16 extension are defined as UNPREDICTABLE if you put them in an IT block (Thumb) or use with any condition other than AL (ARM). LLVM didn't know that, and was happy to conditionalise them. In order to force these instructions to count as not predicable, I had to make a small Tablegen change. The code generation back end mostly decides if an instruction was predicable by looking for something it can identify as a predicate operand; there's an isPredicable bit flag that overrides that check in the positive direction, but nothing that overrides it in the negative direction. (I considered the alternative approach of actually removing the predicate operand from those instructions, but thought that it would be more painful overall for instructions differing only in data type to have different shapes of operand list. This way, the only code that has to notice the difference is the if-converter.) So I've added an isUnpredicable bit alongside isPredicable, and set that bit on the right subset of FP16 instructions, and also on the VSEL, VMAXNM/VMINNM and VRINT[ANPM] families which should be unpredicable for all data types. I've included a couple of representative regression tests, both of which previously caused an fp16 instruction to be conditionalised in ARM state and (with -arm-no-restrict-it) to be put in an IT block in Thumb. Reviewers: SjoerdMeijer, t.p.northover, efriedma Reviewed By: efriedma Subscribers: jdoerfert, javed.absar, kristof.beyls, hiraditya, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D57823 llvm-svn: 354768
* [SelectionDAG] Add a OPC_CheckChild2CondCode to SelectionDAGISel to remove a ↵Craig Topper2019-02-254-2/+40
| | | | | | | | | | MoveChild and MoveParent pair. OPC_CheckCondCode is always used as operand 2 of a setcc. And its always surrounded by a MoveChild2 and a MoveParent. By having a dedicated opcode for this case we can reduce the number of bytes needed for this pattern from 4 bytes to 2. This saves ~3000 bytes in the X86 table. llvm-svn: 354763
* Fix missing C++ mode commentsMatt Arsenault2019-02-211-1/+1
| | | | llvm-svn: 354590
* Add support for pointer types in patternsTom Stellard2019-02-205-2/+33
| | | | | | | | | | | | | | | | | | | | | | | | 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
* [MC] Make SubtargetFeatureKV only store one FeatureBitset and use an ↵Craig Topper2019-02-181-6/+6
| | | | | | | | | | | | 'unsigned' to hold the value. This class is used for two difference tablegen generated tables. For one of the tables the Value FeatureBitset only has one bit set. For the other usage the Implies field was unused. This patch changes the Value field to just be an unsigned. For the usage that put a real vector in bitset, we now use the previously unused Implies field and leave the Value field unused instead. This is good for a 16K reduction in the size of llc on my local build with all targets enabled. llvm-svn: 354243
* [tablegen] Add locations to many PrintFatalError() callsDaniel Sanders2019-02-1213-80/+140
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: While working on the GISel Combiner, I noticed I was producing location-less error messages fairly often and set about fixing this. In the process, I noticed quite a few places elsewhere in TableGen that also neglected to include a relevant location. This patch adds locations to errors that relate to a specific record (or a field within it) and also have easy access to the relevant location. This is particularly useful when multiclasses are involved as many of these errors refer to the full name of a record and it's difficult to guess which substring is grep-able. Unfortunately, tablegen currently only supports Record granularity so it's not currently possible to point at a specific Init so these sometimes point at the record that caused the error rather than the precise origin of the error. Reviewers: bogner, aditya_nandakumar, volkan, aemerson, paquette, nhaehnle Reviewed By: nhaehnle Subscribers: jdoerfert, nhaehnle, asb, rbar, johnrusso, simoncook, apazos, sabuasal, niosHD, jrtc27, zzheng, edward-jones, rogfer01, MartinMosbeck, brucehoult, the_o, PkmX, jocewei, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D58077 llvm-svn: 353862
* [tblgen] Add a timer covering the time spent reading the Instruction defsDaniel Sanders2019-02-112-0/+15
| | | | | | | | | | | | | | | This patch adds a -time-regions option to tablegen that can enable timers (currently only one) that assess the performance of tablegen itself. This can be useful for identifying scaling problems with tablegen backends. This particular timer has allowed me to ignore time that is not attributed the GISel combiner pass. It's useful by itself but it is particularly useful in combination with https://reviews.llvm.org/D52954 which causes this period of time to be annotated within Xcode Instruments which in turn allows profile samples and recorded allocations attributed to reading instructions to be filtered out. llvm-svn: 353763
* [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
* Fix typo in comment, NFCIKrasimir Georgiev2019-02-051-1/+1
| | | | llvm-svn: 353176
OpenPOWER on IntegriCloud