summaryrefslogtreecommitdiffstats
path: root/llvm/test/TableGen
Commit message (Collapse)AuthorAgeFilesLines
...
* [globalisel][tablegen] Compute available feature bits correctly.Daniel Sanders2017-04-291-3/+14
| | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: Predicate<> now has a field to indicate how often it must be recomputed. Currently, there are two frequencies, per-module (RecomputePerFunction==0) and per-function (RecomputePerFunction==1). Per-function predicates are currently recomputed more frequently than necessary since the only predicate in this category is cheap to test. Per-module predicates are now computed in getSubtargetImpl() while per-function predicates are computed in selectImpl(). Tablegen now manages the PredicateBitset internally. It should only be necessary to add the required includes. Also fixed a problem revealed by the test case where constrainSelectedInstRegOperands() would attempt to tie operands that BuildMI had already tied. Reviewers: ab, qcolombet, t.p.northover, rovka, aditya_nandakumar Reviewed By: rovka Subscribers: kristof.beyls, igorb, llvm-commits Differential Revision: https://reviews.llvm.org/D32491 llvm-svn: 301750
* [globalisel][tablegen] Add support for RegisterOperand.Daniel Sanders2017-04-221-1/+2
| | | | | | | | | | | | | | | | | | Summary: It functions just like RegisterClass except that the class is obtained from a field. Depends on D31761. Reviewers: ab, qcolombet, t.p.northover, rovka, kristof.beyls, aditya_nandakumar Reviewed By: ab Subscribers: dberris, llvm-commits, igorb Differential Revision: https://reviews.llvm.org/D32229 llvm-svn: 301080
* [globalisel][tablegen] Revise API for ComplexPattern operands to improve ↵Daniel Sanders2017-04-221-10/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | flexibility. Summary: Some targets need to be able to do more complex rendering than just adding an operand or two to an instruction. For example, it may need to insert an instruction to extract a subreg first, or it may need to perform an operation on the operand. In SelectionDAG, targets would create SDNode's to achieve the desired effect during the complex pattern predicate. This worked because SelectionDAG had a form of garbage collection that would take care of SDNode's that were created but not used due to a later predicate rejecting a match. This doesn't translate well to GlobalISel and the churn was wasteful. The API changes in this patch enable GlobalISel to accomplish the same thing without the waste. The API is now: InstructionSelector::OptionalComplexRendererFn selectArithImmed(MachineOperand &Root) const; where Root is the root of the match. The return value can be omitted to indicate that the predicate failed to match, or a function with the signature ComplexRendererFn can be returned. For example: return OptionalComplexRendererFn( [=](MachineInstrBuilder &MIB) { MIB.addImm(Immed).addImm(ShVal); }); adds two immediate operands to the rendered instruction. Immed and ShVal are captured from the predicate function. As an added bonus, this also reduces the amount of information we need to provide to GIComplexOperandMatcher. Depends on D31418 Reviewers: aditya_nandakumar, t.p.northover, qcolombet, rovka, ab, javed.absar Reviewed By: ab Subscribers: dberris, kristof.beyls, igorb, llvm-commits Differential Revision: https://reviews.llvm.org/D31761 llvm-svn: 301079
* [globalisel][tablegen] Import SelectionDAG's rule predicates and support the ↵Daniel Sanders2017-04-211-3/+38
| | | | | | | | | | | | | | | | | | | | | | | | | | | | equivalent in GIRule. Summary: The SelectionDAG importer now imports rules with Predicate's attached via Requires, PredicateControl, etc. These predicates are implemented as bitset's to allow multiple predicates to be tested together. However, unlike the MC layer subtarget features, each target only pays for it's own predicates (e.g. AArch64 doesn't have 192 feature bits just because X86 needs a lot). Both AArch64 and X86 derive at least one predicate from the MachineFunction or Function so they must re-initialize AvailableFeatures before each function. They also declare locals in <Target>InstructionSelector so that computeAvailableFeatures() can use the code from SelectionDAG without modification. Reviewers: rovka, qcolombet, aditya_nandakumar, t.p.northover, ab Reviewed By: rovka Subscribers: aemerson, rengolin, dberris, kristof.beyls, llvm-commits, igorb Differential Revision: https://reviews.llvm.org/D31418 llvm-svn: 300993
* Revert r300964 + r300970 - [globalisel][tablegen] Import SelectionDAG's rule ↵Daniel Sanders2017-04-211-38/+3
| | | | | | | | | predicates and support the equivalent in GIRule. It's causing llvm-clang-x86_64-expensive-checks-win to fail to compile and I haven't worked out why. Reverting to make it green while I figure it out. llvm-svn: 300978
* [globalisel][tablegen] Import SelectionDAG's rule predicates and support the ↵Daniel Sanders2017-04-211-3/+38
| | | | | | | | | | | | | | | | | | | | | | | | | | | | equivalent in GIRule. Summary: The SelectionDAG importer now imports rules with Predicate's attached via Requires, PredicateControl, etc. These predicates are implemented as bitset's to allow multiple predicates to be tested together. However, unlike the MC layer subtarget features, each target only pays for it's own predicates (e.g. AArch64 doesn't have 192 feature bits just because X86 needs a lot). Both AArch64 and X86 derive at least one predicate from the MachineFunction or Function so they must re-initialize AvailableFeatures before each function. They also declare locals in <Target>InstructionSelector so that computeAvailableFeatures() can use the code from SelectionDAG without modification. Reviewers: rovka, qcolombet, aditya_nandakumar, t.p.northover, ab Reviewed By: rovka Subscribers: aemerson, rengolin, dberris, kristof.beyls, llvm-commits, igorb Differential Revision: https://reviews.llvm.org/D31418 llvm-svn: 300964
* [MVT][SVE] Scalable vector MVTs (2/3)Amara Emerson2017-04-202-2/+2
| | | | | | | | | | | Adds scalable vector machine value types, and updates the switch statements required for tablegen. Patch by Graham Hunter. Differential Revision: https://reviews.llvm.org/D32018 llvm-svn: 300840
* [globalisel][tablegen] Add experimental support for OperandWithDefaultOps, ↵Daniel Sanders2017-04-121-0/+107
| | | | | | | | | | | | | | | | | | | | | | PredicateOperand, and OptionalDefOperand Summary: As far as instruction selection is concerned, all three appear to be same thing. Support for these operands is experimental since AArch64 doesn't make use of them and the in-tree targets that do use them (AMDGPU for OperandWithDefaultOps, AMDGPU/ARM/Hexagon/Lanai for PredicateOperand, and ARM for OperandWithDefaultOps) are not using tablegen-erated GlobalISel yet. Reviewers: rovka, aditya_nandakumar, t.p.northover, qcolombet, ab Reviewed By: rovka Subscribers: inglorion, aemerson, rengolin, mehdi_amini, dberris, kristof.beyls, igorb, tpr, llvm-commits Differential Revision: https://reviews.llvm.org/D31135 llvm-svn: 300037
* [globalisel][tablegen] Fix patterns involving multiple ComplexPatterns.Daniel Sanders2017-04-051-0/+77
| | | | | | | | | | | | | | | | | | | | | | | | | | Summary: Temporaries are now allocated to operands instead of predicates and this allocation is used to correctly pair up the rendered operands with the matched operands. Previously, ComplexPatterns were allocated temporaries independently in the Src Pattern and Dst Pattern, leading to mismatches. Additionally, the Dst Pattern failed to account for the allocated index and therefore always used temporary 0, 1, ... when it should have used base+0, base+1, ... Thanks to Aditya Nandakumar for noticing the bug. Depends on D30539 Reviewers: ab, t.p.northover, qcolombet, rovka, aditya_nandakumar Reviewed By: rovka Subscribers: igorb, dberris, kristof.beyls, llvm-commits Differential Revision: https://reviews.llvm.org/D31054 llvm-svn: 299538
* [tablegen][globalisel] Add support for nested instruction matching.Daniel Sanders2017-04-041-2/+91
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: Lift the restrictions that prevented the tree walking introduced in the previous change and add support for patterns like: (G_ADD (G_MUL (G_SEXT $src1), (G_SEXT $src2)), $src3) -> SMADDWrrr $dst, $src1, $src2, $src3 Also adds support for G_SEXT and G_ZEXT to support these cases. One particular aspect of this that I should draw attention to is that I've tried to be overly conservative in determining the safety of matches that involve non-adjacent instructions and multiple basic blocks. This is intended to be used as a cheap initial check and we may add a more expensive check in the future. The current rules are: * Reject if any instruction may load/store (we'd need to check for intervening memory operations. * Reject if any instruction has implicit operands. * Reject if any instruction has unmodelled side-effects. See isObviouslySafeToFold(). Reviewers: t.p.northover, javed.absar, qcolombet, aditya_nandakumar, ab, rovka Reviewed By: ab Subscribers: igorb, dberris, llvm-commits, kristof.beyls Differential Revision: https://reviews.llvm.org/D30539 llvm-svn: 299430
* [tablegen][globalisel] Capture instructions into locals and related ↵Daniel Sanders2017-03-201-61/+84
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | infrastructure for multiple instructions matches. Summary: Prepare the way for nested instruction matching support by having actions like CopyRenderer look up operands in the RuleMatcher rather than a specific InstructionMatcher. This allows actions to reference any operand from any matched instruction. It works by checking the 'shape' of the match and capturing each matched instruction to a local variable. If the shape is wrong (not enough operands, leaf nodes where non-leafs are expected, etc.), then the rule exits early without checking the predicates. Once we've captured the instructions, we then test the predicates as before (except using the local variables). If the match is successful, then we render the new instruction as before using the local variables. It's not noticable in this patch but by the time we support multiple instruction matching, this patch will also cause a significant improvement to readability of the emitted code since MRI.getVRegDef(I->getOperand(0).getReg()) will simply be MI1 after emitCxxCaptureStmts(). This isn't quite NFC because I've also fixed a bug that I'm surprised we haven't encountered yet. It now checks there are at least the expected number of operands before accessing them with getOperand(). Depends on D30531 Reviewers: t.p.northover, qcolombet, aditya_nandakumar, ab, rovka Reviewed By: rovka Subscribers: dberris, kristof.beyls, llvm-commits Differential Revision: https://reviews.llvm.org/D30535 llvm-svn: 298257
* [globalisel][tblgen] Add support for ComplexPatternsDaniel Sanders2017-03-141-1/+2
| | | | | | | | | | | | | | | | | | | Summary: Adds a new kind of MachineOperand: MO_Placeholder. This operand must not appear in the MIR and only exists as a way of creating an 'uninitialized' operand until a matcher function overwrites it. Depends on D30046, D29712 Reviewers: t.p.northover, ab, rovka, aditya_nandakumar, javed.absar, qcolombet Reviewed By: qcolombet Subscribers: dberris, kristof.beyls, llvm-commits Differential Revision: https://reviews.llvm.org/D30089 llvm-svn: 297782
* [globalisel] Decouple src pattern operands from dst pattern operands.Daniel Sanders2017-02-241-10/+62
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: This isn't testable for AArch64 by itself so this patch also adds support for constant immediates in the pattern and physical register uses in the result. The new IntOperandMatcher matches the constant in patterns such as '(set $rd:GPR32, (G_XOR $rs:GPR32, -1))'. It's always safe to fold immediates into an instruction so this is the first rule that will match across multiple BB's. The Renderer hierarchy is responsible for adding operands to the result instruction. Renderers can copy operands (CopyRenderer) or add physical registers (in particular %wzr and %xzr) to the result instruction in any order (OperandMatchers now import the operand names from SelectionDAG to allow renderers to access any operand). This allows us to emit the result instruction for: %1 = G_XOR %0, -1 --> %1 = ORNWrr %wzr, %0 %1 = G_XOR -1, %0 --> %1 = ORNWrr %wzr, %0 although the latter is untested since the matcher/importer has not been taught about commutativity yet. Added BuildMIAction which can build new instructions and mutate them where possible. W.r.t the mutation aspect, MatchActions are now told the name of an instruction they can recycle and BuildMIAction will emit mutation code when the renderers are appropriate. They are appropriate when all operands are rendered using CopyRenderer and the indices are the same as the matcher. This currently assumes that all operands have at least one matcher. Finally, this change also fixes a crash in AArch64InstructionSelector::select() caused by an immediate operand passing isImm() rather than isCImm(). This was uncovered by the other changes and was detected by existing tests. Depends on D29711 Reviewers: t.p.northover, ab, qcolombet, rovka, aditya_nandakumar, javed.absar Reviewed By: rovka Subscribers: aemerson, dberris, kristof.beyls, llvm-commits Differential Revision: https://reviews.llvm.org/D29712 llvm-svn: 296131
* [globalisel] OperandPredicateMatcher's shouldn't need to generate the ↵Daniel Sanders2017-02-201-4/+4
| | | | | | | | | | | | | | | | | | | | | | | | MachineOperand expr. NFC Summary: Each OperandPredicateMatcher shouldn't need to know how to generate the expression to reference a MachineOperand. The OperandMatcher should provide it. In addition to separating responsibilities, this also lays some groundwork for decoupling source patterns from destination patterns to allow invented operands or operands provided by GlobalISel's equivalent to the ComplexPattern<> class. Depends on D29709 Reviewers: t.p.northover, ab, rovka, qcolombet, aditya_nandakumar Reviewed By: ab Subscribers: dberris, kristof.beyls, llvm-commits, igorb Differential Revision: https://reviews.llvm.org/D29710 llvm-svn: 295668
* [GlobalISel] Print the matched patterns using an action.Ahmed Bougacha2017-02-041-0/+2
| | | | | | | | This lets us split out PatternToMatch from the top-level RuleMatcher, where it doesn't really belong. That, in turn, lets us eventually generate RuleMatchers from non-SelectionDAG sources. llvm-svn: 294076
* [GlobalISel] Add a test for the tablegen selector emitter backend.Ahmed Bougacha2017-02-041-0/+56
| | | | llvm-svn: 294075
* TableGen: Fix infinite recursion in RegisterBankEmitterTom Stellard2017-01-301-0/+15
| | | | | | | | | | | | | | | | Summary: AMDGPU has two register classes with the same set of registers, and this was causing this tablegen backend would get stuck in infinite recursion. Reviewers: dsanders Reviewed By: dsanders Subscribers: tpr, wdng, llvm-commits Differential Revision: https://reviews.llvm.org/D29049 llvm-svn: 293483
* [tablegen] Delete duplicates from a vector without skipping elementsVedant Kumar2016-12-011-0/+84
| | | | | | | | | | | | | | Tablegen's -gen-instr-info pass has a bug in its emitEnums() routine. The function intends for values in a vector to be deduplicated, but it accidentally skips over elements after performing a deletion. I think there are smarter ways of doing this deduplication, but we can do that in a follow-up commit if there's interest. See the thread: [PATCH] TableGen InstrMapping Bug fix. Patch by Tyler Kenney! llvm-svn: 288408
* TableGen: Add operator !orMatt Arsenault2016-11-151-0/+10
| | | | llvm-svn: 286936
* [TableGen] AsmMatcher: Add AsmVariantName to Instruction class.Sam Kolton2016-09-081-0/+46
| | | | | | | | | | | | | | Summary: This allows specifying instructions that are available only in specific assembler variant. If AsmVariantName is specified then instruction will be presented only in MatchTable for this variant. If not specified then assembler variants will be determined based on AsmString. Also this allows splitting assembler match tables in same way as it is done in dissasembler. Reviewers: ab, tstellarAMD, craig.topper, vpykhtin Subscribers: wdng Differential Revision: https://reviews.llvm.org/D24249 llvm-svn: 280952
* tests: accept different TargetOpcode values.Tim Northover2016-07-073-6/+6
| | | | | | | These tests don't actually care about the internal opcode number, but have to be updated whenever we add a new one for GlobalISel. That's bad. llvm-svn: 274774
* [Target] Introduce a generic opcode for bitwise OR: G_OR.Quentin Colombet2016-06-083-6/+6
| | | | | | This G_OR is used in GlobalISel to represent bitwise OR. llvm-svn: 272160
* Introduce a "patchable-function" function attributeSanjoy Das2016-04-193-6/+6
| | | | | | | | | | | | | | | | | Summary: The `"patchable-function"` attribute can be used by an LLVM client to influence LLVM's code generation in ways that makes the generated code easily patchable at runtime (for instance, to redirect control). Right now only one patchability scheme is supported, `"prologue-short-redirect"`, but this can be expanded in the future. Reviewers: joker.eph, rnk, echristo, dberris Subscribers: joker.eph, echristo, mcrosier, llvm-commits Differential Revision: http://reviews.llvm.org/D19046 llvm-svn: 266715
* Declare MVT::SimpleValueType as an int8_t sized enum. This removes 400 bytes ↵Craig Topper2016-04-171-1/+1
| | | | | | | | | | from TargetLoweringBase and probably other places. This required changing several places to print VT enums as strings instead of raw ints since the proper method to use to print became ambiguous. This is probably an improvement anyway. This also appears to save ~8K from an x86 self host build of llc. llvm-svn: 266562
* [GlobalISel][Target] Add an opcode for unconditional branch.Quentin Colombet2016-03-113-6/+6
| | | | llvm-svn: 263259
* SelectionDAG: Make Properties a field of SDPatternOperatorMatt Arsenault2016-02-102-2/+2
| | | | | | | | | Currently you can't specify node properties like commutativity on a PatFrag. If you want to create a PatFrag on a commutative node with a hasOneUse predicate, this enables you to specify that the PatFrag is also commutable. llvm-svn: 260404
* [llvm-tblgen] Stop emitting the intrinsic name matching codeReid Kleckner2016-01-261-36/+0
| | | | | | | | | The AMDGPU backend was the last user of the old StringMatcher recognition code. Move it over to the new lookupLLVMIntrinsicName funciton, which is now improved to handle all of the interesting edge cases exposed by AMDGPU intrinsic names. llvm-svn: 258875
* [GlobalISel] Add a generic machine opcode for ADD.Quentin Colombet2016-01-203-6/+6
| | | | | | | | | | | The selection process being split into separate passes, we need generic opcodes to translate the LLVM IR to target independent code. This patch adds an opcode for addition: G_ADD. Differential Revision: http://reviews.llvm.org/D15472 llvm-svn: 258333
* Add test cases that will show the bug that was fixed in r256725.Craig Topper2016-01-131-0/+24
| | | | llvm-svn: 257584
* Add new vector types for 512-, 1024- and 2048-bit vectorsKrzysztof Parzyszek2015-11-241-1/+1
| | | | | | | | Those types are needed to implement instructions for Hexagon Vector Extensions (HVX): 16x32, 16x64, 32x16, 32x32, 32x64, 64x8, 64x16, 64x32, 128x8, 128x16, 256x8, 512x1, and 1024x1. llvm-svn: 253978
* Revert r253923.Krzysztof Parzyszek2015-11-231-1/+1
| | | | | | Per Eric's request. llvm-svn: 253928
* Add new vector types for 512-, 1024- and 2048-bit vectorsKrzysztof Parzyszek2015-11-231-1/+1
| | | | | | | | Those types are needed to implement instructions for Hexagon Vector Extensions (HVX): 16x32, 16x64, 32x16, 32x32, 32x64, 64x8, 64x16, 64x32, 128x8, 128x16, 256x8, 512x1, and 1024x1. llvm-svn: 253923
* [TableGen] Allow TokenTy in intrinsic signaturesJoseph Tremoulet2015-09-021-1/+1
| | | | | | | | | | | | | | | | | Summary: Add the necessary plumbing so that llvm_token_ty can be used as an argument/return type in intrinsic definitions and correspondingly require TokenTy in function types. TokenTy is an opaque type that has no target lowering, but can be used in machine-independent intrinsics. It is required for the upcoming llvm.eh.padparam intrinsic. Reviewers: majnemer, rnk Subscribers: stoklund, llvm-commits Differential Revision: http://reviews.llvm.org/D12532 llvm-svn: 246651
* TableGen: Support folding casts from bits to intMatt Arsenault2015-07-311-0/+10
| | | | | | | | | | | | | | | This is to fix an incorrect error when trying to initialize DwarfNumbers with a !cast<int> of a bits initializer. getValuesAsListOfInts("DwarfNumbers") would not see an IntInit and instead the cast, so would give up. It seems likely that this could be generalized to attempt the convertInitializerTo for any type. I'm not really sure why the existing code seems to special case the string cast cases when convertInitializerTo seems like it should generally handle this sort of thing. llvm-svn: 243722
* [TableGen] Improve decoding options for non-orthogonal instructionsPetr Pavlu2015-07-153-0/+131
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When FixedLenDecoder matches an input bitpattern of form [01]+ with an instruction bitpattern of form [01?]+ (where 0/1 are static bits and ? are mixed/variable bits) it passes the input bitpattern to a specific instruction decoder method which then makes a final decision whether the bitpattern is a valid instruction or not. This means the decoder must handle all possible values of the variable bits which sometimes leads to opcode rewrites in the decoder method when the instructions are not fully orthogonal. The patch provides a way for the decoder method to say that when it returns Fail it does not necessarily mean the bitpattern is invalid, but rather that the bitpattern is definitely not an instruction that is recognized by the decoder method. The decoder can then try to match the input bitpattern with other possible instruction bitpatterns. For example, this allows to solve a situation on AArch64 where the `MSR (immediate)` instruction has form: 1101 0101 0000 0??? 0100 ???? ???1 1111 but not all values of the ? bits are allowed. The rejected values should be handled by the `extended MSR (register)` instruction: 1101 0101 000? ???? ???? ???? ???? ???? The decoder will first try to decode an input bitpattern that matches both bitpatterns as `MSR (immediate)` but currently this puts the decoder method of `MSR (immediate)` into a situation when it must be able to decode all possible values of the ? bits, i.e. it would need to rewrite the instruction to `MSR (register)` when it is not `MSR (immediate)`. The patch allows to specify that the decoder method cannot determine if the instruction is valid for all variable values. The decoder method can simply return Fail when it knows it is definitely not `MSR (immediate)`. The decoder will then backtrack the decoding and find that it can match the input bitpattern with the more generic `MSR (register)` bitpattern too. Differential Revision: http://reviews.llvm.org/D7174 llvm-svn: 242274
* Use std::bitset for SubtargetFeatures.Michael Kuperstein2015-05-261-1/+1
| | | | | | | | | | | | Previously, subtarget features were a bitfield with the underlying type being uint64_t. Since several targets (X86 and ARM, in particular) have hit or were very close to hitting this bound, switching the features to use a bitset. No functional change. The first several times this was committed (e.g. r229831, r233055), it caused several buildbot failures. Apparently the reason for most failures was both clang and gcc's inability to deal with large numbers (> 10K) of bitset constructor calls in tablegen-generated initializers of instruction info tables. This should now be fixed. llvm-svn: 238192
* [TableGen] Resolve complex def names inside multiclassesHal Finkel2015-05-211-0/+42
| | | | | | | | | We had not been trying hard enough to resolve def names inside multiclasses that had complex concatenations, etc. Now we'll try harder. Patch by Amaury Sechet! llvm-svn: 237877
* Reverting r237234, "Use std::bitset for SubtargetFeatures"Michael Kuperstein2015-05-131-1/+1
| | | | | | | The buildbots are still not satisfied. MIPS and ARM are failing (even though at least MIPS was expected to pass). llvm-svn: 237245
* Use std::bitset for SubtargetFeaturesMichael Kuperstein2015-05-131-1/+1
| | | | | | | | | | | Previously, subtarget features were a bitfield with the underlying type being uint64_t. Since several targets (X86 and ARM, in particular) have hit or were very close to hitting this bound, switching the features to use a bitset. No functional change. The first two times this was committed (r229831, r233055), it caused several buildbot failures. At least some of the ARM and MIPS ones were due to gcc/binutils issues, and should now be fixed. llvm-svn: 237234
* Add support for v1i128 type.Kit Barton2015-04-171-1/+1
| | | | | | | | | | | | The v1i128 type is needed for the quadword add/substract instructions introduced in POWER8. Futhermore, the PowerPC ABI specifies that parameters of type v1i128 are to be passed in a single vector register, while parameters of type i128 are passed in pairs of GPRs. Thus, it is necessary to be able to differentiate between v1i128 and i128 in LLVM. http://reviews.llvm.org/D8564 llvm-svn: 235198
* [TableGen] Prevent invalid code generation when emitting AssemblerPredicate ↵Toma Tabacu2015-04-071-0/+31
| | | | | | | | | | | | | | | | | | | conditions. Summary: The loop which emits AssemblerPredicate conditions also links them together by emitting a '&&'. If the 1st predicate is not an AssemblerPredicate, while the 2nd one is, nothing gets emitted for the 1st one, but we still emit the '&&' because of the 2nd predicate. This generated code looks like "( && Cond2)" and is invalid. Reviewers: dsanders Reviewed By: dsanders Subscribers: dsanders, llvm-commits Differential Revision: http://reviews.llvm.org/D8294 llvm-svn: 234312
* [AVX512] Added intrinsics for VPCMPEQB and VPCMPEQW.Robert Khasanov2014-09-301-1/+1
| | | | | | Added new operand type for intrinsics (IIT_V64) llvm-svn: 218668
* Update test case to match minor formatting change introduced in r218563.Craig Topper2014-09-271-3/+3
| | | | llvm-svn: 218564
* Fix TableGen -gen-disassembler output for bit fields with an offset.Craig Topper2014-09-271-0/+74
| | | | | | | | | This fixes bit assignments like this Inst{7-0} = Foo{9-2} Patch by Steve King. llvm-svn: 218560
* [TableGen] Fully resolve class-instance values before defs in multiclassesAdam Nemet2014-09-161-0/+19
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | By class-instance values I mean 'Class<Arg>' in 'Class<Arg>.Field' or in 'Other<Class<Arg>>' (syntactically s SimpleValue). This is to differentiate from unnamed/anonymous record definitions (syntactically an ObjectBody) which are not affected by this change. Consider the testcase: class Struct<int i> { int I = !shl(i, 1); int J = !shl(I, 1); } class Class<Struct s> { int Class_J = s.J; } multiclass MultiClass<int i> { def Def : Class<Struct<i>>; } defm Defm : MultiClass<2>; Before this fix, DefmDef.Class_J yields !shl(I, 1) instead of 8. This is the sequence of events. We start with this: multiclass MultiClass<int i> { def Def : Class<Struct<i>>; } During ParseDef the anonymous object for the class-instance value is created: multiclass Multiclass<int i> { def anonymous_0 : Struct<i>; def Def : Class<NAME#anonymous_0>; } Then class Struct<i> is added to anonymous_0. Also Class<NAME#anonymous_0> is added to Def: multiclass Multiclass<int i> { def anonymous_0 { int I = !shl(i, 1); int J = !shl(I, 1); } def Def { int Class_J = NAME#anonymous_0.J; } } So far so good but then we move on to instantiating this in the defm by substituting the template arg 'i'. This is how the anonymous prototype looks after fully instantiating. defm Defm = { def Defmanonymous_0 { int I = 4; int J = !shl(I, 1); } Note that we only resolved the reference to the template arg. The non-template-arg reference in 'J' has not been resolved yet. Then we go on to instantiating the Def prototype: def DefmDef { int Class_J = NAME#anonymous_0.J; } Which is resolved to Defmanonymous_0.J and then to !shl(I, 1). When we fully resolve each record in a defm, Defmanonymous_0.J does get set to 8 but that's too late for its use. The patch adds a new attribute to the Record class that indicates that this def is actually a class-instance value that may be *used* by other defs in a multiclass. (This is unlike regular defs which don't reference each other and thus can be resolved indepedently.) They are then fully resolved before the other defs while the multiclass is instantiated. I added vg_leak to the new test. I am not sure if this is necessary but I don't think I have a way to test it. I can also check in without the XFAIL and let the bots test this part. Also tested that X86.td.expanded and AAarch64.td.expanded were unchange before and after this change. (This issue triggering this problem is a WIP patch.) Part of <rdar://problem/17688758> llvm-svn: 217886
* Tablegen fixes for new syntax when initializing bits from variables.Jean-Luc Duprat2014-08-291-1/+3
| | | | | | Followup to r215086. llvm-svn: 216757
* llvm/test/TableGen/*Foreach*.td: Remove XFAIL:vg_leak. They have not been ↵NAKAMURA Takumi2014-08-124-4/+0
| | | | | | failing since r215176. llvm-svn: 215445
* Update BitRecTy::convertValue to allow if expressions with bit values on ↵Pete Cooper2014-08-071-0/+2
| | | | | | both sides of the if llvm-svn: 215087
* Change the { } expression in tablegen to accept sized binary literals which ↵Pete Cooper2014-08-071-0/+24
| | | | | | | | | | | | | | | are not just 0 and 1. It also allows nested { } expressions, as now that they are sized, we can merge pull bits from the nested value. In the current behaviour, everything in { } must have been convertible to a single bit. However, now that binary literals are sized, its useful to be able to initialize a range of bits. So, for example, its now possible to do bits<8> x = { 0, 1, { 0b1001 }, 0, 0b0 } llvm-svn: 215086
* Change BitsInit to inherit from TypedInit.Pete Cooper2014-08-072-2/+2
| | | | | | This is useful in a later patch where binary literals such as 0b000 will become BitsInit values instead of IntInit values. llvm-svn: 215085
OpenPOWER on IntegriCloud