summaryrefslogtreecommitdiffstats
path: root/llvm/utils
Commit message (Collapse)AuthorAgeFilesLines
* [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
* [UpdateTestChecks] Teach the x86 asm parser to skip over the functionChandler Carruth2018-07-131-1/+1
| | | | | | | | | | | | begin label emitted for some routines with personality functions and such. Without this, we don't even recognize such functions as appearing in the output and so don't attach any assertions to them. Happy to tweak this or improve it if folks w/ deeper knowledge of the asm sequences that show up here want. llvm-svn: 336987
* [FileCheck] Implement -v and -vv for tracing matchesJoel E. Denny2018-07-131-33/+137
| | | | | | | | | | | | | | | | | | -v prints all directive pattern matches. -vv additionally prints info that might be noise to users but that can be helpful to FileCheck developers. To maximize code reuse and to make diagnostics more consistent, this patch also adjusts and extends some of the existing diagnostics. CHECK-NOT failures now report variables uses. Many more diagnostics now report the check prefix and kind of directive. Reviewed By: probinson Differential Revision: https://reviews.llvm.org/D47114 llvm-svn: 336967
* [FileCheck] Don't permit overlapping CHECK-DAGJoel E. Denny2018-07-111-12/+53
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | That is, make CHECK-DAG skip matches that overlap the matches of any preceding consecutive CHECK-DAG directives. This change makes CHECK-DAG more consistent with other directives, and there is evidence it makes CHECK-DAG more intuitive and less error-prone. See the RFC discussion starting at: http://lists.llvm.org/pipermail/llvm-dev/2018-May/123010.html Moreover, this behavior enables CHECK-DAG groups for unordered, non-unique strings or patterns. For example, it is useful for verifying output or logs from a parallel program, such as the OpenMP runtime. This patch also implements the command-line option -allow-deprecated-dag-overlap, which reverts CHECK-DAG to the old overlapping behavior. This option should not be used in new tests. It is meant only for the existing tests that are broken by this change and that need time to update. See the following bugzilla issue for tracking of such tests: https://bugs.llvm.org/show_bug.cgi?id=37532 Patches to add -allow-deprecated-dag-overlap to those tests will follow immediately. Reviewed By: probinson Differential Revision: https://reviews.llvm.org/D47106 llvm-svn: 336847
* Revert r336830: [FileCheck] Don't permit overlapping CHECK-DAGJoel E. Denny2018-07-111-53/+12
| | | | | | | Companion patches are failing to commit, and this patch alone breaks many tests. llvm-svn: 336833
* [FileCheck] Don't permit overlapping CHECK-DAGJoel E. Denny2018-07-111-12/+53
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | That is, make CHECK-DAG skip matches that overlap the matches of any preceding consecutive CHECK-DAG directives. This change makes CHECK-DAG more consistent with other directives, and there is evidence it makes CHECK-DAG more intuitive and less error-prone. See the RFC discussion starting at: http://lists.llvm.org/pipermail/llvm-dev/2018-May/123010.html Moreover, this behavior enables CHECK-DAG groups for unordered, non-unique strings or patterns. For example, it is useful for verifying output or logs from a parallel program, such as the OpenMP runtime. This patch also implements the command-line option -allow-deprecated-dag-overlap, which reverts CHECK-DAG to the old overlapping behavior. This option should not be used in new tests. It is meant only for the existing tests that are broken by this change and that need time to update. See the following bugzilla issue for tracking of such tests: https://bugs.llvm.org/show_bug.cgi?id=37532 Patches to add -allow-deprecated-dag-overlap to those tests will follow immediately. Reviewed By: probinson Differential Revision: https://reviews.llvm.org/D47106 llvm-svn: 336830
* [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
* [Utils] Fix gdb pretty printers to work with Python 3.Philip Pfaffe2018-07-091-0/+4
| | | | | | | | Reiterate D23202 for container printers added after the change landed. Differential Revision: https://reviews.llvm.org/D46578 llvm-svn: 336580
* [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
* build_llvm_package.bat: Re-try the build stepsHans Wennborg2018-07-031-5/+5
| | | | | | The build on Windows has been extra flaky recently; retrying helps. llvm-svn: 336192
* [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
* Make email options of find_interesting_reviews more flexible.Kristof Beyls2018-06-291-6/+23
| | | | | | | | | | | | | | | | | | | | | This enables a few requested improvements on the original review of this script at https://reviews.llvm.org/D46192. This introduces 2 new command line options: * --email-report: This option enables specifying who to email the generated report to. This also enables not sending any email and only printing out the report on stdout by not specifying this option on the command line. * --sender: this allows specifying the email address that will be used in the "From" email header. I believe that with these options the script starts having the basic features needed to run it well on a regular basis for a group of developers. Differential Revision: https://reviews.llvm.org/D47930 llvm-svn: 335948
* Revert "Re-land r335297 "[X86] Implement more of x86-64 large and medium PIC ↵Jonas Devlieghere2018-06-282-8/+2
| | | | | | | | | | | | | code models"" Reverting because this is causing failures in the LLDB test suite on GreenDragon. LLVM ERROR: unsupported relocation with subtraction expression, symbol '__GLOBAL_OFFSET_TABLE_' can not be undefined in a subtraction expression llvm-svn: 335894
* 2 VS natvis improvements.Zachary Turner2018-06-281-3/+12
| | | | | | | | Optional<T> was broken due to a change in the class's internals. That is fixed, and additionally a visualizer is added for Expected<T>. llvm-svn: 335892
* [FileCheck] Add CHECK-EMPTY directive for checking for blank linesJames Henderson2018-06-261-10/+44
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Prior to this change, there was no clean way of getting FileCheck to check that a line is completely empty. The expected way of using "CHECK: {{^$}}" does not work because the '^' matches the end of the previous match (this behaviour may be desirable in certain instances). For the same reason, "CHECK-NEXT: {{^$}}" will fail when the previous match was at the end of the line, as the pattern will match there. Using the recommended [[:space:]] to match an explicit new line could also match a space, and thus is not always desired. Literal '\n' matches also do not work. A workaround was suggested in the review, but it is a little clunky. This change adds a new directive that behaves the same as CHECK-NEXT, except that it only matches against empty lines (nothing, not even whitespace, is allowed). As with CHECK-NEXT, it will fail if more than one newline occurs before the next blank line. Example usage: ; test.txt foo bar ; CHECK: foo ; CHECK-EMPTY: ; CHECK-NEXT: bar Differential Revision: https://reviews.llvm.org/D28896 Reviewed by: probinson llvm-svn: 335613
* [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
* [gdb] Escape unprintable bytes in SmallString and StringRefFangrui Song2018-06-261-8/+4
| | | | llvm-svn: 335561
* [gdb] Add pretty printer for ExpectedFangrui Song2018-06-251-21/+45
| | | | | | | | | | Reviewers: dblaikie Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D48512 llvm-svn: 335554
* UBSan blacklist workaround for bot timeoutsVlad Tsyrklevich2018-06-251-0/+5
| | | | | | | | | | | | | | Summary: Workaround for PR37929 Reviewers: eugenis, vitalybuka Reviewed By: eugenis Subscribers: llvm-commits, kcc Differential Revision: https://reviews.llvm.org/D48566 llvm-svn: 335525
* Re-land r335297 "[X86] Implement more of x86-64 large and medium PIC code ↵Reid Kleckner2018-06-252-2/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | models" The large code model allows code and data segments to exceed 2GB, which means that some symbol references may require a displacement that cannot be encoded as a displacement from RIP. The large PIC model even relaxes the assumption that the GOT itself is within 2GB of all code. Therefore, we need a special code sequence to materialize it: .LtmpN: leaq .LtmpN(%rip), %rbx movabsq $_GLOBAL_OFFSET_TABLE_-.LtmpN, %rax # Scratch addq %rax, %rbx # GOT base reg From that, non-local references go through the GOT base register instead of being PC-relative loads. Local references typically use GOTOFF symbols, like this: movq extern_gv@GOT(%rbx), %rax movq local_gv@GOTOFF(%rbx), %rax All calls end up being indirect: movabsq $local_fn@GOTOFF, %rax addq %rbx, %rax callq *%rax The medium code model retains the assumption that the code segment is less than 2GB, so calls are once again direct, and the RIP-relative loads can be used to access the GOT. Materializing the GOT is easy: leaq _GLOBAL_OFFSET_TABLE_(%rip), %rbx # GOT base reg DSO local data accesses will use it: movq local_gv@GOTOFF(%rbx), %rax Non-local data accesses will use RIP-relative addressing, which means we may not always need to materialize the GOT base: movq extern_gv@GOTPCREL(%rip), %rax Direct calls are basically the same as they are in the small code model: They use direct, PC-relative addressing, and the PLT is used for calls to non-local functions. This patch adds reasonably comprehensive testing of LEA, but there are lots of interesting folding opportunities that are unimplemented. I restricted the MCJIT/eh-lg-pic.ll test to Linux, since the large PIC code model is not implemented for MachO yet. Differential Revision: https://reviews.llvm.org/D47211 llvm-svn: 335508
* [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
* [gdb] Use Latin-1 to decode StringRefFangrui Song2018-06-221-1/+1
| | | | llvm-svn: 335387
* [gdb] Update llvm::OptionalFangrui Song2018-06-211-3/+4
| | | | | | | | | | Reviewers: dblaikie Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D48461 llvm-svn: 335303
* Revert r335297 "[X86] Implement more of x86-64 large and medium PIC code models"Reid Kleckner2018-06-212-8/+2
| | | | | | MCJIT can't handle R_X86_64_GOT64 yet. llvm-svn: 335300
* [X86] Implement more of x86-64 large and medium PIC code modelsReid Kleckner2018-06-212-2/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: The large code model allows code and data segments to exceed 2GB, which means that some symbol references may require a displacement that cannot be encoded as a displacement from RIP. The large PIC model even relaxes the assumption that the GOT itself is within 2GB of all code. Therefore, we need a special code sequence to materialize it: .LtmpN: leaq .LtmpN(%rip), %rbx movabsq $_GLOBAL_OFFSET_TABLE_-.LtmpN, %rax # Scratch addq %rax, %rbx # GOT base reg From that, non-local references go through the GOT base register instead of being PC-relative loads. Local references typically use GOTOFF symbols, like this: movq extern_gv@GOT(%rbx), %rax movq local_gv@GOTOFF(%rbx), %rax All calls end up being indirect: movabsq $local_fn@GOTOFF, %rax addq %rbx, %rax callq *%rax The medium code model retains the assumption that the code segment is less than 2GB, so calls are once again direct, and the RIP-relative loads can be used to access the GOT. Materializing the GOT is easy: leaq _GLOBAL_OFFSET_TABLE_(%rip), %rbx # GOT base reg DSO local data accesses will use it: movq local_gv@GOTOFF(%rbx), %rax Non-local data accesses will use RIP-relative addressing, which means we may not always need to materialize the GOT base: movq extern_gv@GOTPCREL(%rip), %rax Direct calls are basically the same as they are in the small code model: They use direct, PC-relative addressing, and the PLT is used for calls to non-local functions. This patch adds reasonably comprehensive testing of LEA, but there are lots of interesting folding opportunities that are unimplemented. Reviewers: chandlerc, echristo Subscribers: hiraditya, llvm-commits Differential Revision: https://reviews.llvm.org/D47211 llvm-svn: 335297
* 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
* [NFC] chmod +x utils/update_analyze_test_checks.pyRoman Lebedev2018-06-151-0/+0
| | | | | | Looks like a simple oversight. llvm-svn: 334825
* [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
OpenPOWER on IntegriCloud