summaryrefslogtreecommitdiffstats
path: root/llvm/utils/TableGen
Commit message (Collapse)AuthorAgeFilesLines
* [mips] Improve diagnostics for instruction mappingAleksandar Beserminji2018-01-081-1/+6
| | | | | | | | | This patch improves diagnostic for case when mapped instruction does not contain a field listed under RowFields. Differential Revision: https://reviews.llvm.org/D41778 llvm-svn: 322004
* [X86] Don't put any EVEX_B instructions in the tablegen generated load ↵Craig Topper2018-01-071-2/+3
| | | | | | | | folding tables. EVEX_B means different things for memory and register forms. The instructions should not be considered equivalent. llvm-svn: 321954
* [TableGen] Make the ambiguous match debug messages from the ↵Craig Topper2018-01-061-0/+6
| | | | | | | | AsmMatcherEmitter slightly more useful. Don't report ambiguous matches on different variants. Print the variant number in the output. llvm-svn: 321938
* [TableGen] Add support of Intrinsics with multiple returnsHal Finkel2018-01-031-1/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | This change deals with intrinsics with multiple outputs, for example load instrinsic with address updated. DAG selection for Instrinsics could be done either through source code or tablegen. Handling all intrinsics in source code would introduce a huge chunk of repetitive code if we have a large number of intrinsic that return multiple values (see NVPTX as an example). While intrinsic class in tablegen supports multiple outputs, tablegen only supports Intrinsics with zero or one output on TreePattern. This appears to be a simple bug in tablegen that is fixed by this change. For Intrinsics defined as: def int_xxx_load_addr_updated: Intrinsic<[llvm_i32_ty, llvm_ptr_ty], [llvm_ptr_ty, llvm_i32_ty], []>; Instruction will be defined as: def L32_X: Inst<(outs reg:$d1, reg:$d2), (ins reg:$s1, reg:$s2), "ld32_x $d1, $d2, $s2", [(set i32:$d1, i32:$d2, (int_xxx_load_addr_updated i32:$s1, i32:$s2))]>; Patch by Wenbo Sun, thanks! Differential Revision: https://reviews.llvm.org/D32888 llvm-svn: 321704
* Avoid int to string conversion in Twine or raw_ostream contexts.Benjamin Kramer2017-12-283-37/+37
| | | | | | Some output changes from uppercase hex to lowercase hex, no other functionality change intended. llvm-svn: 321526
* [TableGen] Print more helpful information in case of type contradictionKrzysztof Parzyszek2017-12-212-21/+39
| | | | | | Dump the failing TreePattern. llvm-svn: 321282
* Do not generate an empty switch statement as it causes MSVC to issue ↵Aaron Ballman2017-12-201-4/+7
| | | | | | diagnostics about switch statements without case or default labels. llvm-svn: 321217
* TableGen: Allow setting SDNodeProperties on intrinsicsMatt Arsenault2017-12-208-52/+120
| | | | | | | | | | | | | | | | | Allows preserving MachineMemOperands on intrinsics through selection. For reasons I don't understand, this is a static property of the pattern and the selector deliberately goes out of its way to drop if not present. Intrinsics already inherit from SDPatternOperator allowing them to be used directly in instruction patterns. SDPatternOperator has a list of SDNodeProperty, but you currently can't set them on the intrinsic. Without SDNPMemOperand, when the node is selected any memory operands are always dropped. Allowing setting this on the intrinsics avoids needing to introduce another equivalent target node just to have SDNPMemOperand set. llvm-svn: 321212
* [globalisel][tablegen] Allow ImmLeaf predicates to use InstructionSelector ↵Daniel Sanders2017-12-201-12/+22
| | | | | | | | | members NFC for currently supported targets. This resolves a problem encountered by targets such as RISCV that reference `Subtarget` in ImmLeaf predicates. llvm-svn: 321176
* [AArch64][SVE] Re-submit patch series for ZIP1/ZIP2Sander de Smalen2017-12-201-11/+15
| | | | | | | | | | | This patch resubmits the SVE ZIP1/ZIP2 patch series consisting of of r320992, r320986, r320973, and r320970 by reverting https://reviews.llvm.org/rL321024. The issue that caused r321024 has been addressed in https://reviews.llvm.org/rL321158, so this patch-series should be safe to resubmit. llvm-svn: 321163
* Silence a bunch of implicit fallthrough warningsAdrian Prantl2017-12-191-0/+1
| | | | llvm-svn: 321114
* [TableGen][GlobalISel] Reset the internal map of RuleMatchers just before ↵Quentin Colombet2017-12-191-3/+4
| | | | | | | | | | | | | | | | | | | the emission Between the creation of the last InstructionMatcher and the first emission of the related Rule, we need to clear the internal map of IDs. We used to do that right after the creation of the main InstructionMatcher when building the rule and although that worked, this is fragile because if for some reason some later code decides to create more InstructionMatcher before the final call to emit, then the IDs would be completely messed up. Move that to the beginning of "emit" so that the IDs are guarantee to be consistent. NFC. llvm-svn: 321053
* [TableGen][GlobalISel] Make the arguments of the Instruction and Operand ↵Quentin Colombet2017-12-181-18/+18
| | | | | | | | | | | | Matchers consistent Move InsnVarID and OpIdx at the beginning of the list of arguments for all the constructors of the OperandMatcher subclasses. This matches what we do for the InstructionMatcher. NFC. llvm-svn: 321031
* [TableGen][GlobalISel] Refactor optimizeRules related bit to allow code reuseQuentin Colombet2017-12-181-12/+23
| | | | | | | | | | | In theory, reapplying optimizeRules on each group matchers should give us a second nesting level on the matching table. In practice, we need more work to make that happen because all the predicates are actually not directly available through the predicate matchers list. NFC. llvm-svn: 321025
* Revert "[AArch64][SVE] Asm" changes, they broke libjpeg_turboReid Kleckner2017-12-181-15/+11
| | | | | | | | | | This reverts changes r320992, r320986, r320973, and r320970. r320970 by itself breaks the test case, and the rest depend on it. Test case will land soon. llvm-svn: 321024
* [TableGen][GlobalISel] Optimize MatchTable for faster instruction selectionQuentin Colombet2017-12-181-17/+194
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | *** Context *** Prior to this patchw, the table generated for matching instruction was straight forward but highly inefficient. Basically, each pattern generates its own set of self contained checks and actions. E.g., TableGen generated: // First pattern CheckNumOperand 3 CheckOpcode G_ADD ... Build ADDrr // Second pattern CheckNumOperand 3 CheckOpcode G_ADD ... Build ADDri // Third pattern CheckNumOperand 3 CheckOpcode G_SUB ... Build SUBrr *** Problem *** Because of that generation, a *lot* of check were redundant between each pattern and were checked every single time until we reach the pattern that matches. E.g., Taking the previous table, let say we are matching a G_SUB, that means we were going to check all the rules for G_ADD before looking at the G_SUB rule. In particular we are going to do: check 3 operands; PASS check G_ADD; FAIL ; Next rule check 3 operands; PASS (but we already knew that!) check G_ADD; FAIL (well it is still not true) ; Next rule check 3 operands; PASS (really!!) check G_SUB; PASS (at last :P) *** Proposed Solution *** This patch introduces a concept of group of rules (GroupMatcher) that share some predicates and only get checked once for the whole group. This patch only creates groups with one nesting level. Conceptually there is nothing preventing us for having deeper nest level. However, the current implementation is not smart enough to share the recording (aka capturing) of values. That limits its ability to do more sharing. For the given example the current patch will generate: // First group CheckOpcode G_ADD // First pattern CheckNumOperand 3 ... Build ADDrr // Second pattern CheckNumOperand 3 ... Build ADDri // Second group CheckOpcode G_SUB // Third pattern CheckNumOperand 3 ... Build SUBrr But if we allowed several nesting level, it could create a sub group for the checknumoperand 3. (We would need to call optimizeRules on the rules within a group.) *** Result *** With only one level of nesting, the instruction selection pass is up to 4x faster. For instance, one instruction now takes 500 checks, instead of 24k! With more nesting we could get in the tens I believe. Differential Revision: https://reviews.llvm.org/D39034 rdar://problem/34670699 llvm-svn: 321017
* [AArch64][SVE] Asm: Improve diagnostics further when +sve is not specifiedSander de Smalen2017-12-181-6/+7
| | | | | | | | | | | | | | Summary: Patch [4/4] in a series to add parsing of predicates and properly parse SVE ZIP1/ZIP2 instructions. This patch further improves diagnostic messages for when the SVE feature is not specified. Reviewers: rengolin, fhahn, olista01, echristo, efriedma Reviewed By: fhahn Subscribers: sdardis, aemerson, javed.absar, tschuett, llvm-commits, kristof.beyls Differential Revision: https://reviews.llvm.org/D40363 llvm-svn: 320992
* [TableGen][AsmMatcherEmitter] Only choose specific diagnostic for enabled ↵Sander de Smalen2017-12-181-5/+8
| | | | | | | | | | | | | | | | | | | | | | | instruction Summary: When emitting a diagnostic for an invalid operand, a specific diagnostic should only be reported when the instruction being matched is actually enabled by the feature flags. Patch [3/4] in a series to add parsing of predicates and properly parse SVE ZIP1/ZIP2 instructions. This patch fixes bogus diagnostic messages for when the SVE feature is not specified. Reviewers: rengolin, craig.topper, olista01, sdardis, stoklund Reviewed By: olista01, sdardis Subscribers: fhahn, javed.absar, llvm-commits Differential Revision: https://reviews.llvm.org/D40362 llvm-svn: 320986
* [TableGen][GlobalISel] Make the different Matcher comparableQuentin Colombet2017-12-151-0/+52
| | | | | | | | | This opens refactoring opportunities in the match table now that we can check that two predicates are the same. NFC. llvm-svn: 320890
* [TableGen][GlobalISel] Fix unused variable warning in release modeQuentin Colombet2017-12-151-0/+1
| | | | | | | | Introduced in r320887. NFC. llvm-svn: 320889
* [TableGen][GlobalISel] Have the predicate directly know which data they are ↵Quentin Colombet2017-12-151-101/+169
| | | | | | | | | | | | | dealing with Prior to this patch, a predicate wouldn't make sense outside of its rule. Indeed, it was only during emitting a rule that a predicate would be made aware of the IDs of the data it is checking. Because of that, predicates could not be moved around or compared between each other. NFC. llvm-svn: 320887
* [TableGen][GlobalISel] Add a common class for all PredicateMatcherQuentin Colombet2017-12-141-48/+44
| | | | | | NFC. llvm-svn: 320767
* Add MVT::v128i1, NFCKrzysztof Parzyszek2017-12-141-0/+1
| | | | | | | Hexagon HVX has type v128i8, comparing two vectors of that type will produce v128i1 types in SelectionDAG. llvm-svn: 320732
* Re-commit: [TableGen] AsmMatcher: Fix bug with reported diagnostic for operand.Sander de Smalen2017-12-141-3/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: The generated diagnostic by the AsmMatcher isn't always applicable to the AsmOperand. This is because the code will only update the diagnostic if it is more specific than the previous diagnostic. However, when having validated operands and 'moved on' to a next operand (for some instruction/alias for which all previous operands are valid), if the diagnostic is InvalidOperand, than that should be set as the diagnostic, not the more specific message about a previous operand for some other instruction/alias candidate. (Re-committed with an extra whitespace in SVEInstrFormats.td to trigger rebuild of AArch64GenAsmMatcher.inc, since the llvm-clang-x86_64-expensive-checks-win builder does not seem to rebuild AArch64GenAsmMatcher.inc with the newly built TableGen due to a missing dependency somewhere (see: http://lists.llvm.org/pipermail/llvm-dev/2017-December/119555.html)) Reviewers: craig.topper, olista01, rengolin, stoklund Reviewed By: olista01 Subscribers: javed.absar, llvm-commits Differential Revision: https://reviews.llvm.org/D40011 llvm-svn: 320711
* Remove redundant includes from utils/TableGen.Michael Zolotukhin2017-12-136-7/+0
| | | | llvm-svn: 320632
* [Targets] Don't automatically include the scheduler class enum from ↵Craig Topper2017-12-131-1/+9
| | | | | | | | | | *GenInstrInfo.inc with GET_INSTRINFO_ENUM. Make targets request is separately. Most of the targets don't need the scheduler class enum. I have an X86 scheduler model change that causes some names in the enum to become about 18000 characters long. This is because using instregex in scheduler models causes the scheduler class to get named with every instruction that matches the regex concatenated together. MSVC has a limit of 4096 characters for an identifier name. Rather than trying to come up with way to reduce the name length, I'm just going to sidestep the problem by not including the enum in X86. llvm-svn: 320552
* Avoid constructing an out-of-range value for an enumeration (which results ↵Richard Smith2017-12-081-5/+4
| | | | | | in UB). llvm-svn: 320206
* [TableGen] Give the option of tolerating duplicate register namesAlex Bradbury2017-12-071-2/+6
| | | | | | | | | | | | | | | | | | A number of architectures re-use the same register names (e.g. for both 32-bit FPRs and 64-bit FPRs). They are currently unable to use the tablegen'erated MatchRegisterName and MatchRegisterAltName, as tablegen (when built with asserts enabled) will fail. When the AllowDuplicateRegisterNames in AsmParser is set, duplicated register names will be tolerated. A backend can then coerce registers to the desired register class by (for instance) implementing validateTargetOperandClass. At least the in-tree Sparc backend could benefit from this, as does RISC-V (single and double precision floating point registers). Differential Revision: https://reviews.llvm.org/D39845 llvm-svn: 320018
* Revert r319691: [globalisel][tablegen] Split atomic load/store into separate ↵Daniel Sanders2017-12-051-88/+43
| | | | | | | | opcode and enable for AArch64. Some concerns were raised with the direction. Revert while we discuss it and look into an alternative llvm-svn: 319739
* [globalisel][tablegen] Split atomic load/store into separate opcode and ↵Daniel Sanders2017-12-041-43/+88
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | enable for AArch64. This patch splits atomics out of the generic G_LOAD/G_STORE and into their own G_ATOMIC_LOAD/G_ATOMIC_STORE. This is a pragmatic decision rather than a necessary one. Atomic load/store has little in implementation in common with non-atomic load/store. They tend to be handled very differently throughout the backend. It also has the nice side-effect of slightly improving the common-case performance at ISel since there's no longer a need for an atomicity check in the matcher table. All targets have been updated to remove the atomic load/store check from the G_LOAD/G_STORE path. AArch64 has also been updated to mark G_ATOMIC_LOAD/G_ATOMIC_STORE legal. There is one issue with this patch though which also affects the extending loads and truncating stores. The rules only match when an appropriate G_ANYEXT is present in the MIR. For example, (G_ATOMIC_STORE (G_TRUNC:s16 (G_ANYEXT:s32 (G_ATOMIC_LOAD:s16 X)))) will match but: (G_ATOMIC_STORE (G_ATOMIC_LOAD:s16 X)) will not. This shouldn't be a problem at the moment, but as we get better at eliminating extends/truncates we'll likely start failing to match in some cases. The current plan is to fix this in a patch that changes the representation of extending-load/truncating-store to allow the MMO to describe a different type to the operation. llvm-svn: 319691
* Revert r319649 - [Asm, ARM] Add fallback diag for multiple invalid operandsOliver Stannard2017-12-041-11/+12
| | | | | | | | This is causing a failure in the llvm-clang-x86_64-expensive-checks-win buildbot, and I can't reproduce it locally, so reverting until I can work out what is wrong. llvm-svn: 319654
* [Asm, ARM] Add fallback diag for multiple invalid operandsOliver Stannard2017-12-041-12/+11
| | | | | | | | | | | | | | | | This adds a "invalid operands for instruction" diagnostic for instructions where there is an instruction encoding with the correct mnemonic and which is available for this target, but where multiple operands do not match those which were provided. This makes it clear that there is some combination of operands that is valid for the current target, which the default diagnostic of "invalid instruction" does not. Since this is a very general error, we only emit it if we don't have a more specific error. Differential revision: https://reviews.llvm.org/D36747 llvm-svn: 319649
* Fix typo in emitted attribute nameMatt Arsenault2017-12-031-1/+1
| | | | | | | Fixes build when using this attribute combination on an intrinsic. llvm-svn: 319625
* [globalisel][tablegen] Add support for relative AtomicOrderingsDaniel Sanders2017-11-303-7/+107
| | | | | | | No test yet because the relevant rules are blocked on the atomic_load, and atomic_store nodes. llvm-svn: 319475
* [globalisel][tablegen] Add support for specific immediates in the match patternDaniel Sanders2017-11-301-0/+8
| | | | | | This enables a few rules such as ARM's uxtb instruction. llvm-svn: 319457
* [globalisel][tablegen] Add support for importing G_ATOMIC_CMPXCHG, ↵Daniel Sanders2017-11-281-38/+82
| | | | | | | | | | G_ATOMICRMW_* rules from SelectionDAG. GIM_CheckNonAtomic has been replaced by GIM_CheckAtomicOrdering to allow it to support a wider range of orderings. This has then been used to import patterns using nodes such as atomic_cmp_swap, atomic_swap, and atomic_load_*. llvm-svn: 319232
* Revert r318822 "[llvm-tblgen] - Stop using std::string in RecordKeeper."George Rimar2017-11-231-4/+5
| | | | | | It reported to have problems with memory sanitizers and DBUILD_SHARED_LIBS=ON. llvm-svn: 318899
* [llvm-tblgen] - Stop using std::string in RecordKeeper.George Rimar2017-11-221-5/+4
| | | | | | | | | | | RecordKeeper::getDef() is a hot place, it shows up in profiling and it creates std::string instance for each search in RecordMap though RecordKeeper::RecordMap can use StringRef as a key instead to avoid that. Patch do that change. Differential revision: https://reviews.llvm.org/D40170 llvm-svn: 318822
* [SelectionDAG] Add a isel matcher op to check the type of node results other ↵Craig Topper2017-11-221-5/+8
| | | | | | | | than result 0. I plan to use this to check the type of the mask result of masked gathers in the X86 backend. llvm-svn: 318820
* [TableGen] Improve error reportingEvandro Menezes2017-11-213-14/+19
| | | | | | | | | When searching for a resource unit, use the reference location instead of the definition location in case of an error. Differential revision: https://reviews.llvm.org/D40263 llvm-svn: 318803
* [Asm] Improve "too few operands" errorsOliver Stannard2017-11-211-1/+1
| | | | | | | | | | - We can still emit this error if the actual instruction has two or more operands missing compared to the expected one. - We should only emit this error once per instruction. Differential revision: https://reviews.llvm.org/D36746 llvm-svn: 318770
* [Asm] Finish matching once end of formal and actual lists reached (NFC)Oliver Stannard2017-11-211-0/+1
| | | | | | | | | | This is NFC, as the matcher would continue looping up to the maximum number of operands with no effect, but this should improve performance a bit, and makes the debug trace clearer. Differential revision: https://reviews.llvm.org/D36744 llvm-svn: 318769
* Revert r318759 due to make check-all failure on WindowsSander de Smalen2017-11-211-2/+3
| | | | llvm-svn: 318768
* [TableGen] AsmMatcher: Fix bug with reported diagnostic for operand.Sander de Smalen2017-11-211-3/+2
| | | | | | | | | | | | | | | | | Summary: The generated diagnostic by the AsmMatcher isn't always applicable to the AsmOperand. This is because the code will only update the diagnostic if it is more specific than the previous diagnostic. However, when having validated operands and 'moved on' to a next operand (for some instruction/alias for which all previous operands are valid), if the diagnostic is InvalidOperand, than that should be set as the diagnostic, not the more specific message about a previous operand for some other instruction/alias candidate. Reviewers: craig.topper, olista01, rengolin, stoklund Reviewed By: olista01 Subscribers: javed.absar, llvm-commits Differential Revision: https://reviews.llvm.org/D40011 llvm-svn: 318759
* [AArch64][TableGen] Skip tied result operands for InstAliasSander de Smalen2017-11-201-2/+15
| | | | | | | | | | | | | | | | | | | | Summary: This patch fixes an issue so that the right alias is printed when the instruction has tied operands. It checks the number of operands in the resulting instruction as opposed to the alias, and then skips over tied operands that should not be printed in the alias. This allows to generate the preferred assembly syntax for the AArch64 'ins' instruction, which should always be displayed as 'mov' according to the ARM Architecture Reference Manual. Several unit tests have changed as a result, but only to reflect the preferred disassembly. Some other InstAlias patterns (movk/bic/orr) needed a slight adjustment to stop them becoming the default and breaking other unit tests. Please note that the patch is mostly the same as https://reviews.llvm.org/D29219 which was reverted because of an issue found when running TableGen with the Address Sanitizer. That issue has been addressed in this iteration of the patch. Reviewers: rengolin, stoklund, huntergr, SjoerdMeijer, rovka Reviewed By: rengolin, SjoerdMeijer Subscribers: fhahn, aemerson, javed.absar, kristof.beyls, llvm-commits Differential Revision: https://reviews.llvm.org/D40030 llvm-svn: 318650
* [globalisel][tablegen] Generalize pointer-type inference by introducing ↵Daniel Sanders2017-11-183-4/+18
| | | | | | | | | | | | | | | ptypeN. NFC ptypeN is functionally the same as typeN except that it informs the SelectionDAG importer that an operand should be treated as a pointer even if it was written as iN. This is important for patterns that use iN instead of iPTR to represent pointers. E.g.: (set GPR64:$dst, (load GPR64:$addr)) Previously, this was handled as a hardcoded special case for the appropriate operands to G_LOAD and G_STORE. llvm-svn: 318574
* Fix a bunch more layering of CodeGen headers that are in TargetDavid Blaikie2017-11-172-2/+2
| | | | | | | | All these headers already depend on CodeGen headers so moving them into CodeGen fixes the layering (since CodeGen depends on Target, not the other way around). llvm-svn: 318490
* [globalisel][tablegen] Generate rule coverage and use it to identify ↵Daniel Sanders2017-11-161-4/+54
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | untested rules Summary: This patch adds a LLVM_ENABLE_GISEL_COV which, like LLVM_ENABLE_DAGISEL_COV, causes TableGen to instrument the generated table to collect rule coverage information. However, LLVM_ENABLE_GISEL_COV goes a bit further than LLVM_ENABLE_DAGISEL_COV. The information is written to files (${CMAKE_BINARY_DIR}/gisel-coverage-* by default). These files can then be concatenated into ${LLVM_GISEL_COV_PREFIX}-all after which TableGen will read this information and use it to emit warnings about untested rules. This technique could also be used by SelectionDAG and can be further extended to detect hot rules and give them priority over colder rules. Usage: * Enable LLVM_ENABLE_GISEL_COV in CMake * Build the compiler and run some tests * cat gisel-coverage-[0-9]* > gisel-coverage-all * Delete lib/Target/*/*GenGlobalISel.inc* * Build the compiler Known issues: * ${LLVM_GISEL_COV_PREFIX}-all must be generated as a manual step due to a lack of a portable 'cat' command. It should be the concatenation of all ${LLVM_GISEL_COV_PREFIX}-[0-9]* files. * There's no mechanism to discard coverage information when the ruleset changes Depends on D39742 Reviewers: ab, qcolombet, t.p.northover, aditya_nandakumar, rovka Reviewed By: rovka Subscribers: vsk, arsenm, nhaehnle, mgorny, kristof.beyls, javed.absar, igorb, llvm-commits Differential Revision: https://reviews.llvm.org/D39747 llvm-svn: 318356
* [Docs] Add tablegen backend for target opcode documentationOliver Stannard2017-11-144-0/+240
| | | | | | | | | | This is a tablegen backend to generate documentation for the opcodes that exist for each target. For each opcode, it lists the assembly string, the names and types of all operands, and the flags and predicates that apply to the opcode. Differential revision: https://reviews.llvm.org/D31025 llvm-svn: 318155
* [tablegen] Handle atomic predicates for ordering inside tablegen. NFC.Daniel Sanders2017-11-132-1/+64
| | | | | | | | | | | | | | | | Similar to r315841, GlobalISel and SelectionDAG require different code for the common atomic predicates due to differences in the representation. Even without that, differences in the IR (SDNode vs MachineInstr) require differences in the C++ predicate. This patch moves the implementation of the common atomic predicates related to ordering into tablegen so that it can handle these differences. It's NFC for SelectionDAG since it emits equivalent code and it's NFC for GlobalISel since the rules involving the relevant predicates are still rejected by the importer. llvm-svn: 318102
OpenPOWER on IntegriCloud