summaryrefslogtreecommitdiffstats
path: root/llvm/utils/TableGen/CodeGenInstruction.cpp
Commit message (Collapse)AuthorAgeFilesLines
* [AArch64] Add isAuthenticated predicate to MCInstDescVedant Kumar2020-01-101-0/+1
| | | | | | | | | | Add a predicate to MCInstDesc that allows tools to determine whether an instruction authenticates a pointer. This can be used by diagnostic tools to hint at pointer authentication failures. Differential Revision: https://reviews.llvm.org/D70329 rdar://55089604
* TableGen/GlobalISel: Fix pattern matching of immarg literalsMatt Arsenault2020-01-091-10/+12
| | | | | | | | | | | | | | | | | For arguments that are not expected to be materialized with G_CONSTANT, this was emitting predicates which could never match. It was first adding a meaningless LLT check, which would always fail due to the operand not being a register. Infer the cases where a literal should check for an immediate operand, instead of a register This avoids needing to invent a special way of representing timm literal values. Also handle immediate arguments in GIM_CheckLiteralInt. The comments stated it handled isImm() and isCImm(), but that wasn't really true. This unblocks work on the selection of all of the complicated AMDGPU intrinsics in future commits.
* GlobalISel: Add target pre-isel instructionsMatt Arsenault2019-10-071-0/+1
| | | | | | | | | | | | | | Allows targets to introduce regbankselectable pseudo-instructions. Currently the closet feature to this is an intrinsic. However this requires creating a public intrinsic declaration. This litters the public intrinsic namespace with operations we don't necessarily want to expose to IR producers, and would rather leave as private to the backend. Use a new instruction bit. A previous attempt tried to keep using enum value ranges, but it turned into a mess. llvm-svn: 373937
* Allow target to handle STRICT floating-point nodesUlrich Weigand2019-06-051-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The ISD::STRICT_ nodes used to implement the constrained floating-point intrinsics are currently never passed to the target back-end, which makes it impossible to handle them correctly (e.g. mark instructions are depending on a floating-point status and control register, or mark instructions as possibly trapping). This patch allows the target to use setOperationAction to switch the action on ISD::STRICT_ nodes to Legal. If this is done, the SelectionDAG common code will stop converting the STRICT nodes to regular floating-point nodes, but instead pass the STRICT nodes to the target using normal SelectionDAG matching rules. To avoid having the back-end duplicate all the floating-point instruction patterns to handle both strict and non-strict variants, we make the MI codegen explicitly aware of the floating-point exceptions by introducing two new concepts: - A new MCID flag "mayRaiseFPException" that the target should set on any instruction that possibly can raise FP exception according to the architecture definition. - A new MI flag FPExcept that CodeGen/SelectionDAG will set on any MI instruction resulting from expansion of any constrained FP intrinsic. Any MI instruction that is *both* marked as mayRaiseFPException *and* FPExcept then needs to be considered as raising exceptions by MI-level codegen (e.g. scheduling). Setting those two new flags is straightforward. The mayRaiseFPException flag is simply set via TableGen by marking all relevant instruction patterns in the .td files. The FPExcept flag is set in SDNodeFlags when creating the STRICT_ nodes in the SelectionDAG, and gets inherited in the MachineSDNode nodes created from it during instruction selection. The flag is then transfered to an MIFlag when creating the MI from the MachineSDNode. This is handled just like fast-math flags like no-nans are handled today. This patch includes both common code changes required to implement the new features, and the SystemZ implementation. Reviewed By: andrew.w.kaylor Differential Revision: https://reviews.llvm.org/D55506 llvm-svn: 362663
* [ARM] Make fullfp16 instructions not conditionalisable.Simon Tatham2019-02-251-1/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | More or less all the instructions defined in the v8.2a full-fp16 extension are defined as UNPREDICTABLE if you put them in an IT block (Thumb) or use with any condition other than AL (ARM). LLVM didn't know that, and was happy to conditionalise them. In order to force these instructions to count as not predicable, I had to make a small Tablegen change. The code generation back end mostly decides if an instruction was predicable by looking for something it can identify as a predicate operand; there's an isPredicable bit flag that overrides that check in the positive direction, but nothing that overrides it in the negative direction. (I considered the alternative approach of actually removing the predicate operand from those instructions, but thought that it would be more painful overall for instructions differing only in data type to have different shapes of operand list. This way, the only code that has to notice the difference is the if-converter.) So I've added an isUnpredicable bit alongside isPredicable, and set that bit on the right subset of FP16 instructions, and also on the VSEL, VMAXNM/VMINNM and VRINT[ANPM] families which should be unpredicable for all data types. I've included a couple of representative regression tests, both of which previously caused an fp16 instruction to be conditionalised in ARM state and (with -arm-no-restrict-it) to be put in an IT block in Thumb. Reviewers: SjoerdMeijer, t.p.northover, efriedma Reviewed By: efriedma Subscribers: jdoerfert, javed.absar, kristof.beyls, hiraditya, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D57823 llvm-svn: 354768
* [tablegen] Add locations to many PrintFatalError() callsDaniel Sanders2019-02-121-22/+46
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: While working on the GISel Combiner, I noticed I was producing location-less error messages fairly often and set about fixing this. In the process, I noticed quite a few places elsewhere in TableGen that also neglected to include a relevant location. This patch adds locations to errors that relate to a specific record (or a field within it) and also have easy access to the relevant location. This is particularly useful when multiclasses are involved as many of these errors refer to the full name of a record and it's difficult to guess which substring is grep-able. Unfortunately, tablegen currently only supports Record granularity so it's not currently possible to point at a specific Init so these sometimes point at the record that caused the error rather than the precise origin of the error. Reviewers: bogner, aditya_nandakumar, volkan, aemerson, paquette, nhaehnle Reviewed By: nhaehnle Subscribers: jdoerfert, nhaehnle, asb, rbar, johnrusso, simoncook, apazos, sabuasal, niosHD, jrtc27, zzheng, edward-jones, rogfer01, MartinMosbeck, brucehoult, the_o, PkmX, jocewei, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D58077 llvm-svn: 353862
* Update the file headers across all of the LLVM projects in the monorepoChandler Carruth2019-01-191-4/+3
| | | | | | | | | | | | | | | | | to reflect the new license. We understand that people may be surprised that we're moving the header entirely to discuss the new license. We checked this carefully with the Foundation's lawyer and we believe this is the correct approach. Essentially, all code in the project is now made available by the LLVM project under our new license, so you will see that the license headers include that license only. Some of our contributors have contributed code under our old license, and accordingly, we have retained a copy of our old license notice in the top-level files in each project and repository. llvm-svn: 351636
* [ARM][MC] Move information about variadic register defs into tablegenOliver Stannard2018-12-031-0/+1
| | | | | | | | | | | | | | | | | | | Currently, variadic operands on an MCInst are assumed to be uses, because they come after the defs. However, this is not always the case, for example the Arm/Thumb LDM instructions write to a variable number of registers. This adds a property of instruction definitions which can be used to mark variadic operands as defs. This only affects MCInst, because MachineInstruction already tracks use/def per operand in each instance of the instruction, so can already represent this. This property can then be checked in MCInstrDesc, allowing us to remove some special cases in ARMAsmParser::isITBlockTerminator. Differential revision: https://reviews.llvm.org/D54853 llvm-svn: 348114
* [TableGen] Better error checking for TIED_TO constraints.Simon Tatham2018-11-281-29/+68
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | There are quite strong constraints on how you can use the TIED_TO constraint between MC operands, many of which are currently not checked until compiler run time. MachineVerifier enforces that operands can only be tied together in pairs (no three-way ties), and MachineInstr::tieOperands enforces that one of the tied operands must be an output operand (def) and the other must be an input operand (use). Now we check these at TableGen time, so that if you violate any of them in a new instruction definition, you find out immediately, instead of having to wait until you compile something that makes code generation hit one of those assertions. Also in this commit, all the error reports in ParseConstraint now include the name and source location of the def where the problem happened, so that if you do trigger any of these errors, it's easier to find the part of your TableGen input where you made the mistake. The trunk sources already build successfully with this additional error check, so I think no in-tree target has any of these problems. Reviewers: fhahn, lhames, nhaehnle, MatzeB Reviewed By: MatzeB Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D53815 llvm-svn: 347743
* [WebAssembly] Add isEHScopeReturn instruction propertyHeejin Ahn2018-08-211-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | Summary: So far, `isReturn` property is used to mean both a return instruction from a functon and the end of an EH scope, a scope that starts with a EH scope entry BB and ends with a catchret or a cleanupret instruction. Because WinEH uses funclets, all EH-scope-ending instructions are also real return instruction from a function. But for wasm, they only serve as the end marker of an EH scope but not a return instruction that exits a function. This mismatch caused incorrect prolog and epilog generation in wasm EH scopes. This patch fixes this. This patch is in the same vein with rL333045, which splits `MachineBasicBlock::isEHFuncletEntry` into `isEHFuncletEntry` and `isEHScopeEntry`. Reviewers: dschuff Subscribers: sbc100, jgravelle-google, sunfish, llvm-commits Differential Revision: https://reviews.llvm.org/D50653 llvm-svn: 340325
* [cfi-verify] Support AArch64.Joel Galenson2018-07-131-0/+1
| | | | | | | | | | | | 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-131-0/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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][AsmMatcherEmitter] Allow tied operands of different classes in ↵Sander de Smalen2018-06-181-2/+8
| | | | | | | | | | | | | | | | | | | | | | 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-181-3/+1
| | | | | | | | | | | | 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][MIPS][ARM] New machine instruction property 'isMoveReg'Petar Jovanovic2018-05-231-0/+1
| | | | | | | | | | | | | This property is needed in order to follow values movement between registers. This property is used in TII to implement method that returns true if simple copy like instruction is recognized, along with source and destination machine operands. Patch by Nikola Prica. Differential Revision: https://reviews.llvm.org/D45204 llvm-svn: 333093
* [FastISel] Permit instructions to be skipped for FastISel generation.Simon Dardis2018-05-221-0/+1
| | | | | | | | | | | | | | | | | | | Some ISA's such as microMIPS32(R6) have instructions which are near identical for code generation purposes, e.g. xor and xor16. These instructions take the same value types for operands and return values, have the same instruction predicates and map to the same ISD opcode. (These instructions do differ by register classes.) In such cases, the FastISel generator rejects the instruction definition. This patch borrows the 'FastIselShouldIgnore' bit from rL129692 and enables applying it to an instruction definition. Reviewers: mcrosier Differential Revision: https://reviews.llvm.org/D46953 llvm-svn: 332983
* [globalisel][tablegen] Generalize pointer-type inference by introducing ↵Daniel Sanders2017-11-181-0/+11
| | | | | | | | | | | | | | | 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
* [TableGen] : CodeGenInsrtuction modify to range loop. NFC.Javed Absar2017-10-061-2/+2
| | | | llvm-svn: 315050
* TableGen support for parameterized register class informationKrzysztof Parzyszek2017-09-141-3/+3
| | | | | | | | | | | | | | | | | | | | | | | | | This replaces TableGen's type inference to operate on parameterized types instead of MVTs, and as a consequence, some interfaces have changed: - Uses of MVTs are replaced by ValueTypeByHwMode. - EEVT::TypeSet is replaced by TypeSetByHwMode. This affects the way that types and type sets are printed, and the tests relying on that have been updated. There are certain users of the inferred types outside of TableGen itself, namely FastISel and GlobalISel. For those users, the way that the types are accessed have changed. For typical scenarios, these replacements can be used: - TreePatternNode::getType(ResNo) -> getSimpleType(ResNo) - TreePatternNode::hasTypeSet(ResNo) -> hasConcreteType(ResNo) - TypeSet::isConcrete -> TypeSetByHwMode::isValueTypeByHwMode(false) For more information, please refer to the review page. Differential Revision: https://reviews.llvm.org/D31951 llvm-svn: 313271
* [TableGen] Add EncoderMethod to RegisterOperandSam Kolton2017-05-151-0/+1
| | | | | | | | Reviewers: stoklund, grosbach, vpykhtin Differential Revision: https://reviews.llvm.org/D32493 llvm-svn: 303044
* TableGen: Use StringInit instead of std::string for DagInit arg namesMatthias Braun2016-12-051-16/+16
| | | | llvm-svn: 288644
* TableGen: Use StringRef instead of const std::string& in return vals.Matthias Braun2016-12-041-2/+2
| | | | | | | This will allow to switch to a different string storage in an upcoming commit. llvm-svn: 288612
* Apply clang-tidy's 'performance-faster-string-find' check to LLVM.Benjamin Kramer2016-11-301-1/+1
| | | | | | No functionality change intended. llvm-svn: 288235
* This reapplies r281304. The issue was that I had missedSjoerd Meijer2016-09-141-0/+1
| | | | | | to copy the new isAdd field in the tablegen data structure. llvm-svn: 281447
* TableGen: Add hasNoSchedulingInfo to instructionsMatthias Braun2016-03-011-0/+1
| | | | | | | | | | | | | This introduces a new flag that indicates that a specific instruction will never be present when the MachineScheduler runs and therefore needs no scheduling information. This is in preparation for an upcoming commit which checks completeness of a scheduling model when tablegen runs. Differential Revision: http://reviews.llvm.org/D17728 llvm-svn: 262383
* Minor performance tweaks to llvm-tblgen (and a few that might be a good idea)Reid Kleckner2016-02-031-1/+3
| | | | | | | | | | | | | | | | | | | | | | | | | Summary: This patch adds a reserve call to an expensive function (`llvm::LoadIntrinsics`), and may fix a few other low hanging performance fruit (I've put them in comments for now, so we can discuss). **Motivation:** As I'm sure other developers do, when I build LLVM, I build the entire project with the same config (`Debug`, `MinSizeRel`, `Release`, or `RelWithDebInfo`). However, the `Debug` config also builds llvm-tblgen in `Debug` mode. Later build steps that run llvm-tblgen then can actually be the slowest steps in the entire build. Nobody likes slow builds. Reviewers: rnk, dblaikie Differential Revision: http://reviews.llvm.org/D16832 Patch by Alexander G. Riccio llvm-svn: 259683
* Add an OperandNamespace field to Target.td's Operand.Dan Gohman2015-12-221-0/+1
| | | | | | | | For targets to add their own operand types as needed, as advertised in Operand's comment, they need to be able to specify an alternate namespace for OperandType names too. This matches the RegisterOperand class. llvm-svn: 256299
* Replace push_back(Constructor(foo)) with emplace_back(foo) for non-trivial typesBenjamin Kramer2015-05-291-6/+6
| | | | | | | | | | | | | | | | | | | | If the type isn't trivially moveable emplace can skip a potentially expensive move. It also saves a couple of characters. Call sites were found with the ASTMatcher + some semi-automated cleanup. memberCallExpr( argumentCountIs(1), callee(methodDecl(hasName("push_back"))), on(hasType(recordDecl(has(namedDecl(hasName("emplace_back")))))), hasArgument(0, bindTemporaryExpr( hasType(recordDecl(hasNonTrivialDestructor())), has(constructExpr()))), unless(isInTemplateInstantiation())) No functional change intended. llvm-svn: 238602
* Add support for the convergent flag at the MC and MachineInstr levels.Owen Anderson2015-05-281-0/+1
| | | | llvm-svn: 238450
* Reverted 230471 - gather scatter handling in table gen.Elena Demikhovsky2015-03-011-1/+0
| | | | llvm-svn: 230892
* AVX-512: Gather and Scatter patternsElena Demikhovsky2015-02-251-0/+1
| | | | | | | | | | | | | | | Gather and scatter instructions additionally write to one of the source operands - mask register. In this case Gather has 2 destination values - the loaded value and the mask. Till now we did not support code gen pattern for gather - the instruction was generated from intrinsic only and machine node was hardcoded. When we introduce the masked_gather node, we need to select instruction automatically, in the standard way. I added a flag "hasTwoExplicitDefs" that allows to handle 2 destination operands. (Some code in the X86InstrFragmentsSIMD.td is commented out, just to split one big patch in many small patches) llvm-svn: 230471
* Target: Allow target specific operand typesTom Stellard2015-01-121-2/+5
| | | | | | | | | | | | | | | | | | | This adds two new fields to the RegisterOperand TableGen class: string OperandNamespace = "MCOI"; string OperandType = "OPERAND_REGISTER"; These fields can be used to specify a target specific operand type, which will be stored in the OperandType member of the MCOperandInfo object. This can be useful for targets that need to store some extra information about operands that cannot be expressed using the target independent types. For example, in the R600 backend, there are operands which can take either registers or immediates and it is convenient to be able to specify this in the TableGen definitions. llvm-svn: 225661
* Clean up static analyzer warnings.Michael Ilseman2014-12-121-1/+1
| | | | | | | | | Clang's static analyzer found several potential cases of undefined behavior, use of un-initialized values, and potentially null pointer dereferences in tablegen, Support, MC, and ADT. This cleans them up with specific assertions on the assumptions of the code. llvm-svn: 224154
* Remove neverHasSideEffects support from TableGen CodeGenInstruction. ↵Craig Topper2014-11-261-4/+0
| | | | | | Everyone should use hasSideEffects now. llvm-svn: 222809
* Add isInsertSubreg property.Quentin Colombet2014-08-201-0/+1
| | | | | | | | | | | | | This patch adds a new property: isInsertSubreg and the related target hooks: TargetIntrInfo::getInsertSubregInputs and TargetInstrInfo::getInsertSubregLikeInputs to specify that a target specific instruction is a (kind of) INSERT_SUBREG. The approach is similar to r215394. <rdar://problem/12702965> llvm-svn: 216139
* Add isExtractSubreg property.Quentin Colombet2014-08-201-0/+1
| | | | | | | | | | | | | This patch adds a new property: isExtractSubreg and the related target hooks: TargetIntrInfo::getExtractSubregInputs and TargetInstrInfo::getExtractSubregLikeInputs to specify that a target specific instruction is a (kind of) EXTRACT_SUBREG. The approach is similar to r215394. <rdar://problem/12702965> llvm-svn: 216130
* Add isRegSequence property.Quentin Colombet2014-08-111-0/+1
| | | | | | | | | | | This patch adds a new property: isRegSequence and the related target hooks: TargetIntrInfo::getRegSequenceInputs and TargetInstrInfo::getRegSequenceLikeInputs to specify that a target specific instruction is a (kind of) REG_SEQUENCE. <rdar://problem/12702965> llvm-svn: 215394
* Change BitsInit to inherit from TypedInit.Pete Cooper2014-08-071-0/+15
| | | | | | This is useful in a later patch where binary literals such as 0b000 will become BitsInit values instead of IntInit values. llvm-svn: 215085
* TableGen: use correct MIOperand when printing aliasesTim Northover2014-05-151-0/+17
| | | | | | | | | | | | | | Previously, TableGen assumed that every aliased operand consumed precisely 1 MachineInstr slot (this was reasonable because until a couple of days ago, nothing more complicated was eligible for printing). This allows a couple more ARM64 aliases to print so we can remove the special code. On the X86 side, I've gone for explicit AT&T size specifiers as the default, so turned off a few of the aliases that would have just started printing. llvm-svn: 208880
* TableGen/ARM64: print aliases even if they have syntax variants.Tim Northover2014-05-151-2/+6
| | | | | | | To get at least one use of the change (and some actual tests) in with its commit, I've enabled the AArch64 & ARM64 NEON mov aliases. llvm-svn: 208867
* [C++11] More 'nullptr' conversion. In some cases just using a boolean check ↵Craig Topper2014-04-151-6/+6
| | | | | | instead of comparing to nullptr. llvm-svn: 206254
* tblgen: Twinify PrintFatalError.Benjamin Kramer2014-03-291-11/+11
| | | | | | No functionality change. llvm-svn: 205110
* TableGen: avoid dereferencing nullptr variableTim Northover2014-03-291-6/+10
| | | | | | | ARM64 ended up reaching odder parts of TableGen alias generation than current backends and caused a segfault. llvm-svn: 205089
* Shrink the size of CodeGenInstruction a little bit by using bitfields. 32 ↵Craig Topper2014-02-051-4/+7
| | | | | | bools seemed excessive. llvm-svn: 200829
* Add an instruction deprecation feature to TableGen.Joey Gouly2013-09-121-0/+14
| | | | | | | | | | | | | | | | | | | | | | The 'Deprecated' class allows you to specify a SubtargetFeature that the instruction is deprecated on. The 'ComplexDeprecationPredicate' class allows you to define a custom predicate that is called to check for deprecation. For example: ComplexDeprecationPredicate<"MCR"> would mean you would have to define the following function: bool getMCRDeprecationInfo(MCInst &MI, MCSubtargetInfo &STI, std::string &Info) Which returns 'false' for not deprecated, and 'true' for deprecated and store the warning message in 'Info'. The MCTargetAsmParser constructor was chaned to take an extra argument of the MCInstrInfo class, so out-of-tree targets will need to be changed. llvm-svn: 190598
* ARM: use TableGen patterns to select CMOV operations.Tim Northover2013-08-221-1/+1
| | | | | | | | | | | | Back in the mists of time (2008), it seems TableGen couldn't handle the patterns necessary to match ARM's CMOV node that we convert select operations to, so we wrote a lot of fairly hairy C++ to do it for us. TableGen can deal with it now: there were a few minor differences to CodeGen (see tests), but nothing obviously worse that I could see, so we should probably address anything that *does* come up in a localised manner. llvm-svn: 188995
* Fixing a warning about control reaching the end of a non-void function.Aaron Ballman2013-08-161-0/+1
| | | | llvm-svn: 188524
* Sort the #include lines for utils/...Chandler Carruth2012-12-041-3/+3
| | | | | | | I've tried to find main moudle headers where possible, but the TableGen stuff may warrant someone else looking at it. llvm-svn: 169251
* Remove exception handling usage from tblgen.Joerg Sonnenberger2012-10-251-47/+49
| | | | | | | | | | | Most places can use PrintFatalError as the unwinding mechanism was not used for anything other than printing the error. The single exception was CodeGenDAGPatterns.cpp, where intermediate errors during type resolution were ignored to simplify incremental platform development. This use is replaced by an error flag in TreePattern and bailout earlier in various places if it is set. llvm-svn: 166712
* Allow the commuted form of tied-operand constraints in tablegen ("$dst = $src",Lang Hames2012-10-201-5/+6
| | | | | | rather than "$src = $dst"). llvm-svn: 166382
OpenPOWER on IntegriCloud