summaryrefslogtreecommitdiffstats
path: root/llvm/utils/TableGen
Commit message (Collapse)AuthorAgeFilesLines
* Fix build bot after r338521Ulrich Weigand2018-08-011-1/+1
| | | | llvm-svn: 338522
* [SystemZ, TableGen] Fix shift count handlingUlrich Weigand2018-08-011-24/+20
| | | | | | | | | | | | | | | | | | | | | | | | | The DAG combiner logic to simplify AND masks in shift counts is invalid. While it is true that the SystemZ shift instructions ignore all but the low 6 bits of the shift count, it is still invalid to simplify the AND masks while the DAG still uses the standard shift operators (which are *not* defined to match the SystemZ instruction behavior). Instead, this patch performs equivalent operations during instruction selection. For completely removing the AND, this now happens via additional DAG match patterns implemented by a multi-alternative PatFrags. For simplifying a 32-bit AND to a 16-bit AND, the existing DAG patterns were already mostly OK, they just needed an output XForm to actually truncate the immediate value. Unfortunately, the latter change also exposed a bug in TableGen: it seems XForms are currently only handled correctly for direct operands of the outermost operation node. This patch also fixes that bug by simply recurring through the whole pattern. This should be NFC for all other targets. Differential Revision: https://reviews.llvm.org/D50096 llvm-svn: 338521
* Revert r338365: [X86] Improved sched models for X86 BT*rr instructions.Simon Pilgrim2018-07-312-94/+0
| | | | | | | | https://reviews.llvm.org/D49243 Contains WIP code that should not have been included. llvm-svn: 338369
* [X86] Improved sched models for X86 BT*rr instructions.Andrew V. Tischenko2018-07-312-0/+94
| | | | | | https://reviews.llvm.org/D49243 llvm-svn: 338365
* [windows] Don't inline fieldFromInstruction on WindowsStella Stamenova2018-07-251-1/+7
| | | | | | | | | | | | | | | Summary: The VS compiler (on Windows) has a bug which results in fieldFromInstruction being optimized out in some circumstances. This only happens in *release no debug info* builds that have assertions *turned off* - in all other situations the function is not inlined, so the functionality is correct. All of the bots have assertions turned on, so this path is not regularly tested. The workaround is to not inline the function on Windows - if the bug is fixed in a later release of the VS compiler, the noinline specification can be removed. The test that consistently reproduces this is Lanai v11.txt test. Reviewers: asmith, labath, zturner Subscribers: dblaikie, stella.stamenova, aprantl, JDevlieghere, llvm-commits Differential Revision: https://reviews.llvm.org/D49753 llvm-svn: 337942
* [Tablegen][PredicateExpander] Add the ability to define checks for invalid ↵Andrea Di Biagio2018-07-182-0/+10
| | | | | | | | registers. This was discussed in review D49436. llvm-svn: 337378
* [Tablegen][PredicateExpander] Fix a bug in `expandCheckImmOperand`.Andrea Di Biagio2018-07-171-4/+4
| | | | | | | | | | Function `expandCheckImmOperand` should always check if the input machine instruction is passed by reference before calling method `getOperand()` on it. Found while working on a patch that relies on `expandCheckImmOperand` to expand a scheduling predicate. llvm-svn: 337294
* [TableGen] std::move vectors into TreePatternNode.Craig Topper2018-07-152-10/+12
| | | | llvm-svn: 337121
* [TableGen] Remove what seems to be an unnecessary std::map copy.Craig Topper2018-07-151-9/+6
| | | | | | The comment says the copy was made so it could be destroyed in the following loop, but the original map wasn't used after the loop. llvm-svn: 337120
* [TableGen] Add some std::move to the PatternToMatch constructor.Craig Topper2018-07-151-1/+1
| | | | | | The are two vectors passed by value to the constructor. We should be able to move them into the object. llvm-svn: 337114
* [TableGen] Suppress type validation when parsing pattern fragmentsUlrich Weigand2018-07-132-4/+22
| | | | | | | | | | | | | | | | | | | | | | | | | | Currently, any attempt to define a PatFrag involving any floating-point only (or vector only) node causes a hard assertion failure in TableGen if the current target does not have any floating-point (or vector) types. This is annoying if you want to provide convenience fragments in common code (e.g. include/llvm/Target/TargetSelectionDAG.td) that is parsed on all platforms, including those that miss such types. But really, there's no reason not accept this when parsing the fragment -- of course it would be an error for such a target to actually *use* such a fragment anywhere, but as long as it doesn't, I think TableGen shouldn't error out. The immediate cause of the assertion failure is the test inside the ValidateOnExit destructor. This patch simply disables that check while infering types during parsing of pattern fragments (only). Reviewed By: hfinkel, kparzysz Differential Revision: https://reviews.llvm.org/D48887 llvm-svn: 337023
* [Tablegen] Optimize isSubsetOf() in AsmMatcherEmitter.cpp. NFCMarcello Maggioni2018-07-131-2/+10
| | | | | | | | | | | | | isSubsetOf() could be very slow if the hierarchy of the RegisterClasses of the target is very complicated. This is mainly caused by the fact that isSubset() is called multiple times over the same SuperClass of a register class if this ends up being the super class of a register class from multiple paths. Differential Revision: https://reviews.llvm.org/D49124 llvm-svn: 337020
* [cfi-verify] Support AArch64.Joel Galenson2018-07-134-0/+4
| | | | | | | | | | | | This patch adds support for AArch64 to cfi-verify. This required three changes to cfi-verify. First, it generalizes checking if an instruction is a trap by adding a new isTrap flag to TableGen (and defining it for x86 and AArch64). Second, the code that ensures that the operand register is not clobbered between the CFI check and the indirect call needs to allow a single dereference (in x86 this happens as part of the jump instruction). Third, we needed to ensure that return instructions are not counted as indirect branches. Technically, returns are indirect branches and can be covered by CFI, but LLVM's forward-edge CFI does not protect them, and x86 does not consider them, so we keep that behavior. In addition, we had to improve AArch64's code to evaluate the branch target of a MCInst to handle calls where the destination is not the first operand (which it often is not). Differential Revision: https://reviews.llvm.org/D48836 llvm-svn: 337007
* [TableGen] Support multi-alternative pattern fragmentsUlrich Weigand2018-07-136-375/+391
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | A TableGen instruction record usually contains a DAG pattern that will describe the SelectionDAG operation that can be implemented by this instruction. However, there will be cases where several different DAG patterns can all be implemented by the same instruction. The way to represent this today is to write additional patterns in the Pattern (or usually Pat) class that map those extra DAG patterns to the instruction. This usually also works fine. However, I've noticed cases where the current setup seems to require quite a bit of extra (and duplicated) text in the target .td files. For example, in the SystemZ back-end, there are quite a number of instructions that can implement an "add-with-overflow" operation. The same instructions also need to be used to implement just plain addition (simply ignoring the extra overflow output). The current solution requires creating extra Pat pattern for every instruction, duplicating the information about which particular add operands map best to which particular instruction. This patch enhances TableGen to support a new PatFrags class, which can be used to encapsulate multiple alternative patterns that may all match to the same instruction. It operates the same way as the existing PatFrag class, except that it accepts a list of DAG patterns to match instead of just a single one. As an example, we can now define a PatFrags to match either an "add-with-overflow" or a regular add operation: def z_sadd : PatFrags<(ops node:$src1, node:$src2), [(z_saddo node:$src1, node:$src2), (add node:$src1, node:$src2)]>; and then use this in the add instruction pattern: defm AR : BinaryRRAndK<"ar", 0x1A, 0xB9F8, z_sadd, GR32, GR32>; These SystemZ target changes are implemented here as well. Note that PatFrag is now defined as a subclass of PatFrags, which means that some users of internals of PatFrag need to be updated. (E.g. instead of using PatFrag.Fragment you now need to use !head(PatFrag.Fragments).) The implementation is based on the following main ideas: - InlinePatternFragments may now replace each original pattern with several result patterns, not just one. - parseInstructionPattern delays calling InlinePatternFragments and InferAllTypes. Instead, it extracts a single DAG match pattern from the main instruction pattern. - Processing of the DAG match pattern part of the main instruction pattern now shares most code with processing match patterns from the Pattern class. - Direct use of main instruction patterns in InferFromPattern and EmitResultInstructionAsOperand is removed; everything now operates solely on DAG match patterns. Reviewed by: hfinkel Differential Revision: https://reviews.llvm.org/D48545 llvm-svn: 336999
* [TableGen] Add a general-purpose JSON backend.Simon Tatham2018-07-111-0/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The aim of this backend is to output everything TableGen knows about the record set, similarly to the default -print-records backend. But where -print-records produces output in TableGen's input syntax (convenient for humans to read), this backend produces it as structured JSON data, which is convenient for loading into standard scripting languages such as Python, in order to extract information from the data set in an automated way. The output data contains a JSON representation of the variable definitions in output 'def' records, and a few pieces of metadata such as which of those definitions are tagged with the 'field' prefix and which defs are derived from which classes. It doesn't dump out absolutely every piece of knowledge it _could_ produce, such as type information and complicated arithmetic operator nodes in abstract superclasses; the main aim is to allow consumers of this JSON dump to essentially act as new backends, and backends don't generally need to depend on that kind of data. The new backend is implemented as an EmitJSON() function similar to all of llvm-tblgen's other EmitFoo functions, except that it lives in lib/TableGen instead of utils/TableGen on the basis that I'm expecting to add it to clang-tblgen too in a future patch. To test it, I've written a Python script that loads the JSON output and tests properties of it based on comments in the .td source - more or less like FileCheck, except that the CHECK: lines have Python expressions after them instead of textual pattern matches. Reviewers: nhaehnle Reviewed By: nhaehnle Subscribers: arichardson, labath, mgorny, llvm-commits Differential Revision: https://reviews.llvm.org/D46054 llvm-svn: 336771
* [TableGen] Fix some bad formatting. NFCCraig Topper2018-07-111-4/+4
| | | | llvm-svn: 336751
* [Power9] Add __float128 builtins for Round To OddStefan Pintilie2018-07-091-1/+3
| | | | | | | | | | | | GCC has builtins for these round to odd instructions: __float128 __builtin_sqrtf128_round_to_odd (__float128) __float128 __builtin_{add,sub,mul,div}f128_round_to_odd (__float128, __float128) __float128 __builtin_fmaf128_round_to_odd (__float128, __float128, __float128) Differential Revision: https://reviews.llvm.org/D47550 llvm-svn: 336578
* [TableGen] Increase the number of supported decoder fix-ups.Sander de Smalen2018-07-051-18/+40
| | | | | | | | | | | | | | | | The vast number of added instructions for SVE causes TableGen to fail with an assertion: Assertion `Delta < 65536U && "disassembler decoding table too large!"' This patch increases the number of supported decoder fix-ups. Reviewers: dmgreen, stoklund, petpav01 Reviewed By: dmgreen Differential Revision: https://reviews.llvm.org/D48937 llvm-svn: 336334
* [X86] Add phony registers for high halves of regs with low halvesKrzysztof Parzyszek2018-07-021-3/+9
| | | | | | | | | | Add registers still missing after r328016 (D43353): - for bits 15-8 of SI, DI, BP, SP (*H), and R8-R15 (*BH), - for bits 31-16 of R8-R15 (*WH). Thanks to Craig Topper for pointing it out. llvm-svn: 336134
* [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
* [IR] Split Intrinsics.inc into enums and implementationsReid Kleckner2018-06-233-30/+53
| | | | | | | | | | | | | | | | | | | Implements PR34259 Intrinsics.h is a very popular header. Most LLVM TUs care about things like dbg_value, but they don't care how they are implemented. After I split these out, IntrinsicImpl.inc is 1.7 MB, so this saves each LLVM TU from scanning 1.7 MB of source that gets pre-processed away. It also means we can modify intrinsic properties without triggering a full rebuild, but that's probably less of a win. I think the next best thing to do would be to split out the target intrinsics into their own header. Very, very few TUs care about target-specific intrinsics. It's very hard to split up the target independent intrinsics like llvm.expect, assume, and dbg.value, though. llvm-svn: 335407
* TableGen/SearchableTables: Support more generic enums and tablesNicolai Haehnle2018-06-211-201/+634
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: This is essentially a rewrite of the backend which introduces TableGen base classes GenericEnum, GenericTable, and SearchIndex. They allow generating custom enums and tables with lookup functions using separately defined records as the underlying database. Also added as part of this change: - Lookup functions may use indices composed of multiple fields. - Instruction fields are supported similar to Intrinsic fields. - When the lookup key has contiguous numeric values, the lookup function will directly index into the table instead of using a binary search. The existing SearchableTable functionality is internally mapped to the new primitives. Change-Id: I444f3490fa1dbfb262d7286a1660a2c4308e9932 Reviewers: arsenm, tra, t.p.northover Subscribers: wdng, llvm-commits Differential Revision: https://reviews.llvm.org/D48013 llvm-svn: 335225
* [X86] Add the ability to force an EVEX2VEX mapping table entry from the .td ↵Craig Topper2018-06-191-71/+30
| | | | | | | | | | | | | | files. Remove remaining manual table entries from the tablegen emitter. This adds an EVEX2VEXOverride string to the X86 instruction class in X86InstrFormats.td. If this field is set it will add manual entry in the EVEX->VEX tables that doesn't check the encoding information. Then use this mechanism to map VMOVDU/A8/16, 128-bit VALIGN, and VPSHUFF/I instructions to VEX instructions. Finally, remove the manual table from the emitter. This has the bonus of fully sorting the autogenerated EVEX->VEX tables by their EVEX instruction enum value. We may be able to use this to do a binary search for the conversion and get rid of the need to create a DenseMap. llvm-svn: 335018
* [X86] Add a new VEX_WPrefix encoding to tag EVEX instruction that have ↵Craig Topper2018-06-193-80/+42
| | | | | | | | | | | | | | VEX.W==1, but can be converted to their VEX equivalent that uses VEX.W==0. EVEX makes heavy use of the VEX.W bit to indicate 64-bit element vs 32-bit elements. Many of the VEX instructions were split into 2 versions with different masking granularity. The EVEX->VEX table generate can collapse the two versions if the VEX version uses is tagged as VEX_WIG. But if the VEX version is instead marked VEX.W==0 we can't combine them because we don't know if there is also a VEX version with VEX.W==1. This patch adds a new VEX_W1X tag that indicates the EVEX instruction encodes with VEX.W==1, but is safe to convert to a VEX instruction with VEX.W==0. This allows us to remove a bunch of manual EVEX->VEX table entries. We may want to look into splitting up the VEX_WPrefix field which would simplify the disassembler. llvm-svn: 335017
* [X86] Encode the EVEX2VEX exception list information in .td files instead of ↵Craig Topper2018-06-181-26/+2
| | | | | | | | the emitter source. Rather than having an exclusion list in tablegen sources, add a flag to the X86 instruction records that can be used to suppress checking for convertibility. llvm-svn: 334971
* [TableGen] Make TiedAsmOperandTable in the AsmMatcher 'static' since its at ↵Craig Topper2018-06-181-2/+2
| | | | | | file scope. llvm-svn: 334957
* [TableGen] Remove unused member variable.Craig Topper2018-06-181-14/+0
| | | | | | I think this became unused after r324196. llvm-svn: 334956
* [TableGen][AsmMatcherEmitter] Allow tied operands of different classes in ↵Sander de Smalen2018-06-182-27/+61
| | | | | | | | | | | | | | | | | | | | | | aliases. Allow a tied operand of a different operand class in InstAliases, so that the operand can be printed (and added to the MC instruction) as the appropriate register. For example, 'GPR64as32', which would be printed/parsed as a 32bit register and should match a tied 64bit register operand, where the former is a sub-register of the latter. This patch also generalizes the constraint checking to an overrideable method in MCTargetAsmParser, so that target asmparsers can specify whether a given operand satisfies the tied register constraint. Reviewers: olista01, rengolin, fhahn, SjoerdMeijer, samparker, dsanders, craig.topper Reviewed By: fhahn Differential Revision: https://reviews.llvm.org/D47714 llvm-svn: 334942
* [TableGen] Prevent double flattening of InstAlias asm strings in the asm ↵Craig Topper2018-06-184-14/+13
| | | | | | | | | | | | matcher emitter. Unlike CodeGenInstruction, CodeGenInstAlias was flatting asm strings in its constructor. For instructions it was the users responsibility to flatten the string. AsmMatcherEmitter didn't know this and treated them the same. This caused double flattening of InstAliases. This is mostly harmless unless the desired assembly string contains curly braces. The second flattening wouldn't know to ignore these and would remove the curly braces. And for variant 1 it would remove the contents of them as well. To mitigate this, this patch makes removes the flattening from the CodeGenIntAlias constructor and modifies AsmWriterEmitter to account for the flattening not having been done. llvm-svn: 334919
* [X86] More additions to the load folding tables based on the autogenerated ↵Craig Topper2018-06-161-4/+6
| | | | | | | | tables. Including more additions for NotMemoryFoldable to remove some entries from the autogenerated table. llvm-svn: 334898
* [globalisel][tablegen] Add support for C++ predicates on PatFrags and use it ↵Daniel Sanders2018-06-153-20/+115
| | | | | | | | | | | | | | | | | | | | | 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
* [X86] Add 'Z' to the internal names of various EVEX instructions for overall ↵Craig Topper2018-06-151-8/+8
| | | | | | consistency. llvm-svn: 334785
* Revert r334764, as it breaks some botsFlorian Hahn2018-06-146-502/+503
| | | | llvm-svn: 334767
* [TableGen] Make TreePatternNode::getChild return a reference (NFC)Florian Hahn2018-06-146-503/+502
| | | | | | | | 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
* [TableGen] Move some shared_ptrs to avoid unnecessary copies (NFC).Florian Hahn2018-06-141-21/+21
| | | | | | Those changes were suggested post-commit for D47463. llvm-svn: 334706
* [TableGen] Make getOnlyTree return a const ref (NFC)Florian Hahn2018-06-132-9/+11
| | | | | | | This avoids some unnecessary copies of shared_ptrs. Those changes were suggested post-commit for D47463. llvm-svn: 334656
* [TableGen] Emit a fatal error on inconsistencies in resource units vs cycles.Clement Courbet2018-06-131-2/+16
| | | | | | | | | | | | | | | | | | | | | Summary: For targets I'm not familiar with, I've automatically made the "default to 1 for each resource" behaviour explicit in the td files. For more obvious cases, I've ventured a fix. Some notes: - Exynos is especially fishy. - AArch64SchedThunderX2T99.td had some truncated entries. If I understand correctly, the person who wrote that interpreted the ResourceCycle as a range. I made the decision to use the upper/lower bound for consistency with the 'Latency' value. I'm sure there is a better choice. - The change to X86ScheduleBtVer2.td is an NFC, it just makes values more explicit. Also see PR37310. Reviewers: RKSimon, craig.topper, javed.absar Subscribers: kristof.beyls, llvm-commits Differential Revision: https://reviews.llvm.org/D46356 llvm-svn: 334586
* [X86] Mark all instructions that have masked store semantics with ↵Craig Topper2018-06-131-16/+2
| | | | | | | | NotMemoryFoldable. Remove dependency on SchedRW from memory table autogenerator. Previously we were whitelisting in instructions based on their SchedRW value. With the masked store instructions explicitly removed via NotMemoryFoldable, we don't seem to need this check anymore. llvm-svn: 334563
* [X86] Remove unnecessary include from one of the tblgen emitters.Craig Topper2018-06-121-1/+0
| | | | llvm-svn: 334530
* [X86] Don't add stores to the autogenerated load folding tables if the ↵Craig Topper2018-06-121-1/+2
| | | | | | | | register and memory operands have different widths. This can cause the amount of the memory written to be changed which would be bad. llvm-svn: 334480
* [X86] Update folding table generator to properly detect RMW arithmetic ↵Craig Topper2018-06-121-2/+4
| | | | | | | | | | instructions. The RMW instructions are detected by reading the SchedRW data, but the RMW instructions have had their SchedRW changed in recent months. This broke the expectation. We probably should fix this to use the mayLoad/mayStore flags if possible. llvm-svn: 334478
* [X86] Enforce agreement of AdSize field when autogenerating load folding ↵Craig Topper2018-06-121-0/+1
| | | | | | table entries. llvm-svn: 334473
* TableGen: Change some pointer parameters to references since they're never ↵David Blaikie2018-06-112-21/+22
| | | | | | null anyway llvm-svn: 334446
* [TableGen] Make better use of std::map::emplace and emplace construct the ↵Craig Topper2018-06-101-9/+10
| | | | | | object in the map rather than moving it into it. Remove a use std::map::find by remembering the return from emplace. llvm-svn: 334380
* [TableGen] Combine two constructors by taking vectors by value instead of ↵Craig Topper2018-06-101-11/+3
| | | | | | trying to support combininations for rvalue and lvalue references. llvm-svn: 334379
* Revert r334374 [TableGen] Move some shared_ptrs to avoid unnecessary copies ↵Florian Hahn2018-06-102-26/+21
| | | | | | | | (NFC). This breaks some builders. llvm-svn: 334376
* [TableGen] Move some shared_ptrs to avoid unnecessary copies (NFC).Florian Hahn2018-06-102-21/+26
| | | | | | Those changes were suggested post-commit for D47463. llvm-svn: 334374
* [tablegen] Improve performance on *GenRegisterInfo.inc by replacing ↵Daniel Sanders2018-06-081-3/+3
| | | | | | | | | | | | | | | | SparseVector with BitVector. NFC Summary: Generating X86GenRegisterInfo.inc and AArch64GenRegisterInfo.inc is 8-9% faster on my build. Reviewers: bogner, javed.absar Reviewed By: bogner Subscribers: llvm-commits, kristof.beyls Differential Revision: https://reviews.llvm.org/D47907 llvm-svn: 334337
* [TableGen] Make DAGInstruction own Pattern to avoid leaking it.Florian Hahn2018-06-082-11/+13
| | | | | | | | | | Reviewers: dsanders, craig.topper, stoklund, nhaehnle Reviewed By: craig.topper Differential Revision: https://reviews.llvm.org/D47525 llvm-svn: 334275
* [X86] Rename vy512mem->vy512xmem and vz256xmem->vz256mem.Craig Topper2018-06-061-4/+4
| | | | | | | | | | | The index size is represented by the letter after the 'v'. The number represents the memory size. If an 'x' appears after the number its means the index register can be from VR128X/VR256X instead of VR128/VR256. As vy512mem uses a VR256X index it should have an x. And vz256mem uses a VR512 index so it shouldn't have an x. I admit these names kind of suck and are confusing. llvm-svn: 334120
OpenPOWER on IntegriCloud