summaryrefslogtreecommitdiffstats
path: root/llvm/utils/TableGen/CodeGenSchedule.h
Commit message (Collapse)AuthorAgeFilesLines
* 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
* [llvm-mca][MC] Add the ability to declare which processor resources model ↵Andrea Di Biagio2018-11-291-2/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | load/store queues (PR36666). This patch adds the ability to specify via tablegen which processor resources are load/store queue resources. A new tablegen class named MemoryQueue can be optionally used to mark resources that model load/store queues. Information about the load/store queue is collected at 'CodeGenSchedule' stage, and analyzed by the 'SubtargetEmitter' to initialize two new fields in struct MCExtraProcessorInfo named `LoadQueueID` and `StoreQueueID`. Those two fields are identifiers for buffered resources used to describe the load queue and the store queue. Field `BufferSize` is interpreted as the number of entries in the queue, while the number of units is a throughput indicator (i.e. number of available pickers for loads/stores). At construction time, LSUnit in llvm-mca checks for the presence of extra processor information (i.e. MCExtraProcessorInfo) in the scheduling model. If that information is available, and fields LoadQueueID and StoreQueueID are set to a value different than zero (i.e. the invalid processor resource index), then LSUnit initializes its LoadQueue/StoreQueue based on the BufferSize value declared by the two processor resources. With this patch, we more accurately track dynamic dispatch stalls caused by the lack of LS tokens (i.e. load/store queue full). This is also shown by the differences in two BdVer2 tests. Stalls that were previously classified as generic SCHEDULER FULL stalls, are not correctly classified either as "load queue full" or "store queue full". About the differences in the -scheduler-stats view: those differences are expected, because entries in the load/store queue are not released at instruction issue stage. Instead, those are released at instruction executed stage. This is the main reason why for the modified tests, the load/store queues gets full before PdEx is full. Differential Revision: https://reviews.llvm.org/D54957 llvm-svn: 347857
* [MCSched] Bind PFM Counters to the CPUs instead of the SchedModel.Clement Courbet2018-10-251-11/+1
| | | | | | | | | | | | | | | | Summary: The pfm counters are now in the ExegesisTarget rather than the MCSchedModel (PR39165). This also compresses the pfm counter tables (PR37068). Reviewers: RKSimon, gchatelet Subscribers: mgrang, llvm-commits Differential Revision: https://reviews.llvm.org/D52932 llvm-svn: 345243
* [tblgen][llvm-mca] Add the ability to describe move elimination candidates ↵Andrea Di Biagio2018-10-121-4/+11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | via tablegen. This patch adds the ability to identify instructions that are "move elimination candidates". It also allows scheduling models to describe processor register files that allow move elimination. A move elimination candidate is an instruction that can be eliminated at register renaming stage. Each subtarget can specify which instructions are move elimination candidates with the help of tablegen class "IsOptimizableRegisterMove" (see llvm/Target/TargetInstrPredicate.td). For example, on X86, BtVer2 allows both GPR and MMX/SSE moves to be eliminated. The definition of 'IsOptimizableRegisterMove' for BtVer2 looks like this: ``` def : IsOptimizableRegisterMove<[ InstructionEquivalenceClass<[ // GPR variants. MOV32rr, MOV64rr, // MMX variants. MMX_MOVQ64rr, // SSE variants. MOVAPSrr, MOVUPSrr, MOVAPDrr, MOVUPDrr, MOVDQArr, MOVDQUrr, // AVX variants. VMOVAPSrr, VMOVUPSrr, VMOVAPDrr, VMOVUPDrr, VMOVDQArr, VMOVDQUrr ], CheckNot<CheckSameRegOperand<0, 1>> > ]>; ``` Definitions of IsOptimizableRegisterMove from processor models of a same Target are processed by the SubtargetEmitter to auto-generate a target-specific override for each of the following predicate methods: ``` bool TargetSubtargetInfo::isOptimizableRegisterMove(const MachineInstr *MI) const; bool MCInstrAnalysis::isOptimizableRegisterMove(const MCInst &MI, unsigned CPUID) const; ``` By default, those methods return false (i.e. conservatively assume that there are no move elimination candidates). Tablegen class RegisterFile has been extended with the following information: - The set of register classes that allow move elimination. - Maxium number of moves that can be eliminated every cycle. - Whether move elimination is restricted to moves from registers that are known to be zero. This patch is structured in three part: A first part (which is mostly boilerplate) adds the new 'isOptimizableRegisterMove' target hooks, and extends existing register file descriptors in MC by introducing new fields to describe properties related to move elimination. A second part, uses the new tablegen constructs to describe move elimination in the BtVer2 scheduling model. A third part, teaches llm-mca how to query the new 'isOptimizableRegisterMove' hook to mark instructions that are candidates for move elimination. It also teaches class RegisterFile how to describe constraints on move elimination at PRF granularity. llvm-mca tests for btver2 show differences before/after this patch. Differential Revision: https://reviews.llvm.org/D53134 llvm-svn: 344334
* [llvm-exegesis] Add support for measuring NumMicroOps.Clement Courbet2018-09-261-1/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: Example output for vzeroall: --- mode: uops key: instructions: - 'VZEROALL' config: '' register_initial_values: cpu_name: haswell llvm_triple: x86_64-unknown-linux-gnu num_repetitions: 10000 measurements: - { debug_string: HWPort0, value: 0.0006, per_snippet_value: 0.0006, key: '3' } - { debug_string: HWPort1, value: 0.0011, per_snippet_value: 0.0011, key: '4' } - { debug_string: HWPort2, value: 0.0004, per_snippet_value: 0.0004, key: '5' } - { debug_string: HWPort3, value: 0.0018, per_snippet_value: 0.0018, key: '6' } - { debug_string: HWPort4, value: 0.0002, per_snippet_value: 0.0002, key: '7' } - { debug_string: HWPort5, value: 1.0019, per_snippet_value: 1.0019, key: '8' } - { debug_string: HWPort6, value: 1.0033, per_snippet_value: 1.0033, key: '9' } - { debug_string: HWPort7, value: 0.0001, per_snippet_value: 0.0001, key: '10' } - { debug_string: NumMicroOps, value: 20.0069, per_snippet_value: 20.0069, key: NumMicroOps } error: '' info: '' assembled_snippet: C5FC77C5FC77C5FC77C5FC77C5FC77C5FC77C5FC77C5FC77C5FC77C5FC77C5FC77C5FC77C5FC77C5FC77C5FC77C5FC77C3 ... Reviewers: gchatelet Subscribers: tschuett, RKSimon, andreadb, llvm-commits Differential Revision: https://reviews.llvm.org/D52539 llvm-svn: 343094
* Attempt to unbreak buidlbot lld-x86_64-darwin13 after r342555.Andrea Di Biagio2018-09-191-1/+1
| | | | | | | | | | | | | | | | | | The reason why build #25777 might have failed is because the SmallVector move constructor is _not_ noexcept, and the stl implementation used by that buildbot calls _VSTD::move_if_noexcept() (according to the backtrace). OpcodeInfo has a default move constructor, and the copy constructor is deleted. However, as far as I can see, SmallVector doesn't declare a noexcept move constructor. So, what I believe it is happening here is that, _VSTD::move_if_noexcept() returns an lvalue reference and not an rvalue reference. This eventually triggers a copy that fails to compile. Hopefully, using a std::vector instead of SmallVector (as it was originally suggested by Simon in the code review) should be enough to unbreak the buildbot. llvm-svn: 342561
* [TableGen][SubtargetEmitter] Add the ability for processor models to ↵Andrea Di Biagio2018-09-191-0/+141
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | describe dependency breaking instructions. This patch adds the ability for processor models to describe dependency breaking instructions. Different processors may specify a different set of dependency-breaking instructions. That means, we cannot assume that all processors of the same target would use the same rules to classify dependency breaking instructions. The main goal of this patch is to provide the means to describe dependency breaking instructions directly via tablegen, and have the following TargetSubtargetInfo hooks redefined in overrides by tabegen'd XXXGenSubtargetInfo classes (here, XXX is a Target name). ``` virtual bool isZeroIdiom(const MachineInstr *MI, APInt &Mask) const { return false; } virtual bool isDependencyBreaking(const MachineInstr *MI, APInt &Mask) const { return isZeroIdiom(MI); } ``` An instruction MI is a dependency-breaking instruction if a call to method isDependencyBreaking(MI) on the STI (TargetSubtargetInfo object) evaluates to true. Similarly, an instruction MI is a special case of zero-idiom dependency breaking instruction if a call to STI.isZeroIdiom(MI) returns true. The extra APInt is used for those targets that may want to select which machine operands have their dependency broken (see comments in code). Note that by default, subtargets don't know about the existence of dependency-breaking. In the absence of external information, those method calls would always return false. A new tablegen class named STIPredicate has been added by this patch to let processor models classify instructions that have properties in common. The idea is that, a MCInstrPredicate definition can be used to "generate" an instruction equivalence class, with the idea that instructions of a same class all have a property in common. STIPredicate definitions are essentially a collection of instruction equivalence classes. Also, different processor models can specify a different variant of the same STIPredicate with different rules (i.e. predicates) to classify instructions. Tablegen backends (in this particular case, the SubtargetEmitter) will be able to process STIPredicate definitions, and automatically generate functions in XXXGenSubtargetInfo. This patch introduces two special kind of STIPredicate classes named IsZeroIdiomFunction and IsDepBreakingFunction in tablegen. It also adds a definition for those in the BtVer2 scheduling model only. This patch supersedes the one committed at r338372 (phabricator review: D49310). The main advantages are: - We can describe subtarget predicates via tablegen using STIPredicates. - We can describe zero-idioms / dep-breaking instructions directly via tablegen in the scheduling models. In future, the STIPredicates framework can be used for solving other problems. Examples of future developments are: - Teach how to identify optimizable register-register moves - Teach how to identify slow LEA instructions (each subtarget defining its own concept of "slow" LEA). - Teach how to identify instructions that have undocumented false dependencies on the output registers on some processors only. It is also (in my opinion) an elegant way to expose knowledge to both external tools like llvm-mca, and codegen passes. For example, machine schedulers in LLVM could reuse that information when internally constructing the data dependency graph for a code region. This new design feature is also an "opt-in" feature. Processor models don't have to use the new STIPredicates. It has all been designed to be as unintrusive as possible. Differential Revision: https://reviews.llvm.org/D52174 llvm-svn: 342555
* Test commit: remove trailing whitespaceJosh Stone2018-09-111-1/+1
| | | | llvm-svn: 341966
* [Tablegen][MCInstPredicate] Removed redundant template argument from class ↵Andrea Di Biagio2018-08-141-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | TIIPredicate, and implemented verification rules for TIIPredicates. This patch removes redundant template argument `TargetName` from TIIPredicate. Tablegen can always infer the target name from the context. So we don't need to force users of TIIPredicate to always specify it. This allows us to better modularize the tablegen class hierarchy for the so-called "function predicates". class FunctionPredicateBase has been added; it is currently used as a building block for TIIPredicates. However, I plan to reuse that class to model other function predicate classes too (i.e. not just TIIPredicates). For example, this can be a first step towards implementing proper support for dependency breaking instructions in tablegen. This patch also adds a verification step on TIIPredicates in tablegen. We cannot have multiple TIIPredicates with the same name. Otherwise, this will cause build errors later on, when tablegen'd .inc files are included by cpp files and then compiled. Differential Revision: https://reviews.llvm.org/D50708 llvm-svn: 339706
* Revert r338365: [X86] Improved sched models for X86 BT*rr instructions.Simon Pilgrim2018-07-311-2/+0
| | | | | | | | https://reviews.llvm.org/D49243 Contains WIP code that should not have been included. llvm-svn: 338369
* [X86] Improved sched models for X86 BT*rr instructions.Andrew V. Tischenko2018-07-311-0/+2
| | | | | | https://reviews.llvm.org/D49243 llvm-svn: 338365
* [Tablegen] Simplify code in CodeGenSchedule. NFCIAndrea Di Biagio2018-04-261-5/+2
| | | | llvm-svn: 330935
* [MC][TableGen] Add optional libpfm counter names for ProcResUnits.Clement Courbet2018-04-101-1/+9
| | | | | | | | | | | | | | | | Summary: Subtargets can define the libpfm counter names that can be used to measure cycles and uops issued on ProcResUnits. This allows making llvm-exegesis available on more targets. Fixes PR36984. Reviewers: gchatelet, RKSimon, andreadb, craig.topper Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D45360 llvm-svn: 329675
* [MC][Tablegen] Allow models to describe the retire control unit for llvm-mca. Andrea Di Biagio2018-04-051-2/+10
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch adds the ability to describe properties of the hardware retire control unit. Tablegen class RetireControlUnit has been added for this purpose (see TargetSchedule.td). A RetireControlUnit specifies the size of the reorder buffer, as well as the maximum number of opcodes that can be retired every cycle. A zero (or negative) value for the reorder buffer size means: "the size is unknown". If the size is unknown, then llvm-mca defaults it to the value of field SchedMachineModel::MicroOpBufferSize. A zero or negative number of opcodes retired per cycle means: "there is no restriction on the number of instructions that can be retired every cycle". Models can optionally specify an instance of RetireControlUnit. There can only be up-to one RetireControlUnit definition per scheduling model. Information related to the RCU (RetireControlUnit) is stored in (two new fields of) MCExtraProcessorInfo. llvm-mca loads that information when it initializes the DispatchUnit / RetireControlUnit (see Dispatch.h/Dispatch.cpp). This patch fixes PR36661. Differential Revision: https://reviews.llvm.org/D45259 llvm-svn: 329304
* [MC][Tablegen] Allow the definition of processor register files in the ↵Andrea Di Biagio2018-04-031-0/+42
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | scheduling model for llvm-mca This patch allows the description of register files in processor scheduling models. This addresses PR36662. A new tablegen class named 'RegisterFile' has been added to TargetSchedule.td. Targets can optionally describe register files for their processors using that class. In particular, class RegisterFile allows to specify: - The total number of physical registers. - Which target registers are accessible through the register file. - The cost of allocating a register at register renaming stage. Example (from this patch - see file X86/X86ScheduleBtVer2.td) def FpuPRF : RegisterFile<72, [VR64, VR128, VR256], [1, 1, 2]> Here, FpuPRF describes a register file for MMX/XMM/YMM registers. On Jaguar (btver2), a YMM register definition consumes 2 physical registers, while MMX/XMM register definitions only cost 1 physical register. The syntax allows to specify an empty set of register classes. An empty set of register classes means: this register file models all the registers specified by the Target. For each register class, users can specify an optional register cost. By default, register costs default to 1. A value of 0 for the number of physical registers means: "this register file has an unbounded number of physical registers". This patch is structured in two parts. * Part 1 - MC/Tablegen * A first part adds the tablegen definition of RegisterFile, and teaches the SubtargetEmitter how to emit information related to register files. Information about register files is accessible through an instance of MCExtraProcessorInfo. The idea behind this design is to logically partition the processor description which is only used by external tools (like llvm-mca) from the processor information used by the llvm machine schedulers. I think that this design would make easier for targets to get rid of the extra processor information if they don't want it. * Part 2 - llvm-mca related * The second part of this patch is related to changes to llvm-mca. The main differences are: 1) class RegisterFile now needs to take into account the "cost of a register" when allocating physical registers at register renaming stage. 2) Point 1. triggered a minor refactoring which lef to the removal of the "maximum 32 register files" restriction. 3) The BackendStatistics view has been updated so that we can print out extra details related to each register file implemented by the processor. The effect of point 3. is also visible in tests register-files-[1..5].s. Differential Revision: https://reviews.llvm.org/D44980 llvm-svn: 329067
* [TableGen] Add a non-default constructor to CodeGenSchedClass and use it via ↵Craig Topper2018-03-221-3/+4
| | | | | | emplace_back to create new SchedClasses instead of using resize(size+1) llvm-svn: 328183
* [SchedModel] Use CodeGenSchedClass::isKeyEqual instead of duplicating code. ↵Simon Pilgrim2018-03-211-1/+2
| | | | | | NFCI. llvm-svn: 328126
* [TableGen] Remove a defaulted function argument that is never called with ↵Craig Topper2018-03-211-1/+1
| | | | | | another value. NFC llvm-svn: 328075
* [TableGen] Move a function from llvm namespace and make it a static ↵Craig Topper2018-03-211-3/+0
| | | | | | | | function. NFC It's only called from one place and is defined just above that use. llvm-svn: 328074
* [TableGen][NFC]Remove dead variable.Clement Courbet2018-01-261-1/+0
| | | | llvm-svn: 323525
* [TableGen] Improve error reportingEvandro Menezes2017-11-211-3/+4
| | | | | | | | | 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
* [MiSched|TableGen] : Tidy up and modernise. NFC.Javed Absar2017-09-131-10/+10
| | | | | | | | | Replacing with range-based loop and substituting 'using'. Reviewed by: @MatzeB Differential Revision: https://reviews.llvm.org/D37748 llvm-svn: 313140
* Revert "Revert "[misched] Extend scheduler to handle unsupported features""Simon Dardis2016-06-241-0/+8
| | | | | | | | This reverts commit r273565. This was an over-eager revert. llvm-svn: 273658
* Revert "[misched] Extend scheduler to handle unsupported features"Simon Dardis2016-06-231-8/+0
| | | | | | | | This reverts commit r273551. Patch contained a wrong check for isUnsupported. llvm-svn: 273565
* [misched] Extend scheduler to handle unsupported featuresSimon Dardis2016-06-231-0/+8
| | | | | | | | | | | | | | | | | | | | | | | Currently isComplete = 1 requires that every instruction must be described, declared unsupported or marked as having no scheduling information for a processor. For some backends such as MIPS, this requirement entails long regex lists of instructions that are unsupported. This patch teaches Tablegen to skip over instructions that are associated with unsupported feature when checking if the scheduling model is complete. Patch by: Daniel Sanders Contributions by: Simon Dardis Reviewers: MatzeB Differential Reviewer: http://reviews.llvm.org/D20522 llvm-svn: 273551
* TableGen/CodeGenSchedule: Move some getAllDerivedDefinitions() calls out of ↵Matthias Braun2016-06-211-0/+3
| | | | | | | | | inner loops This cuts the runtime of the two slowest tblgen invocations in aarch64 in half for me... llvm-svn: 273235
* TableGen: Check scheduling models for completenessMatthias Braun2016-03-011-0/+2
| | | | | | | | | | | | | | | | | | | | | | TableGen checks at compiletime that for scheduling models with "CompleteModel = 1" one of the following holds: - Is marked with the hasNoSchedulingInfo flag - The instruction is a subclass of Sched - There are InstRW definitions in the scheduling model Typical steps necessary to complete a model: - Ensure all pseudo instructions that are expanded before machine scheduling (usually everything handled with EmitYYY() functions in XXXTargetLowering). - If a CPU does not support some instructions mark the corresponding resource unsupported: "WriteRes<WriteXXX, []> { let Unsupported = 1; }". - Add missing scheduling information. Differential Revision: http://reviews.llvm.org/D17747 llvm-svn: 262384
* [TableGen] Use range-based for loops. NFCCraig Topper2016-02-131-0/+2
| | | | llvm-svn: 260809
* Use make_range to reduce mentions of iterator type. NFCCraig Topper2015-12-061-6/+4
| | | | llvm-svn: 254872
* [TblGen] ArrayRefize CodeGenSchedule. No functionality change intended.Benjamin Kramer2015-10-241-19/+20
| | | | llvm-svn: 251187
* Canonicalize header guards into a common format.Benjamin Kramer2014-08-131-2/+2
| | | | | | | | | | Add header guards to files that were missing guards. Remove #endif comments as they don't seem common in LLVM (we can easily add them back if we decide they're useful) Changes made by clang-tidy with minor tweaks. llvm-svn: 215558
* Move SetTheory from utils/TableGen into lib/TableGen so Clang can use it.James Molloy2014-06-171-1/+1
| | | | llvm-svn: 211100
* iterator access to scheduling classesJim Grosbach2014-04-181-0/+22
| | | | llvm-svn: 206552
* [C++11] More 'nullptr' conversion. In some cases just using a boolean check ↵Craig Topper2014-04-161-3/+3
| | | | | | instead of comparing to nullptr. llvm-svn: 206356
* Fix known typosAlp Toker2014-01-241-2/+2
| | | | | | | Sweep the codebase for common typos. Includes some changes to visible function names that were misspelt. llvm-svn: 200018
* Support BufferSize on ProcResGroup for unified MOp schedulers.Andrew Trick2013-06-151-1/+4
| | | | | | And add Sandybridge/Haswell resource buffers. llvm-svn: 184034
* Machine model: verify well-formed processor resource groups.Andrew Trick2013-04-231-0/+3
| | | | llvm-svn: 180161
* Machine model. Allow mixed itinerary classes and SchedRW lists.Andrew Trick2013-03-161-39/+28
| | | | | | | | | | | | | We always supported a mixture of the old itinerary model and new per-operand model, but it required a level of indirection to map itinerary classes to SchedRW lists. This was done for ARM A9. Now we want to define x86 SchedRW lists, with the goal of removing its itinerary classes, but still support the itineraries in the mean time. When I original developed the model, Atom did not have itineraries, so there was no reason to expect this requirement. llvm-svn: 177226
* Fix an uninitialized member variable, found by -fsanitize=bool.Richard Smith2012-12-201-7/+8
| | | | llvm-svn: 170627
* Sort the #include lines for utils/...Chandler Carruth2012-12-041-2/+2
| | | | | | | I've tried to find main moudle headers where possible, but the TableGen stuff may warrant someone else looking at it. llvm-svn: 169251
* TableGen subtarget emitter cleanup.Andrew Trick2012-10-101-0/+3
| | | | | | Consistently evaluate Aliases and Sequences recursively. llvm-svn: 165604
* Added instregex support to TableGen subtarget emitter.Andrew Trick2012-10-031-0/+4
| | | | | | | | This allows the processor-specific machine model to override selected base opcodes without any fanciness. e.g. InstRW<[CoreXWriteVANDP], (instregex "VANDP")>. llvm-svn: 165180
* TableGen subtarget emitter, nearly first class support for SchedAlias.Andrew Trick2012-10-031-10/+16
| | | | | | | | | A processor can now arbitrarily alias one SchedWrite onto another. Only the SchedAlias definition need be within the processor model. The aliased SchedWrite may be a SchedVariant, WriteSequence, or transitively refer to another alias. llvm-svn: 165179
* Machine Model (-schedmodel only). Added SchedAliases.Andrew Trick2012-09-221-8/+23
| | | | | | | Allow subtargets to tie SchedReadWrite types to processor specific sequences or variants. llvm-svn: 164451
* SchedMachineModel: compress the CPU's WriteLatencyTable.Andrew Trick2012-09-191-0/+3
| | | | llvm-svn: 164199
* comment typoAndrew Trick2012-09-181-1/+1
| | | | llvm-svn: 164097
* TableGen subtarget emitter. Use getSchedClassIdx.Andrew Trick2012-09-181-9/+0
| | | | llvm-svn: 164096
* Revert r164061-r164067. Most of the new subtarget emitter.Andrew Trick2012-09-171-1/+10
| | | | | | | I have to work out the Target/CodeGen header dependencies before putting this back. llvm-svn: 164072
* comment typoAndrew Trick2012-09-171-1/+1
| | | | llvm-svn: 164064
* TableGen subtarget emitter. Use getSchedClassIdx.Andrew Trick2012-09-171-9/+0
| | | | llvm-svn: 164063
OpenPOWER on IntegriCloud