summaryrefslogtreecommitdiffstats
path: root/llvm/utils/TableGen/SubtargetEmitter.cpp
Commit message (Collapse)AuthorAgeFilesLines
* [TableGen] Fix a bug that MCSchedClassDesc is interfered between different ↵QingShan Zhang2019-10-111-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | SchedModel Assume that, ModelA has scheduling resource for InstA and ModelB has scheduling resource for InstB. This is what the llvm::MCSchedClassDesc looks like: llvm::MCSchedClassDesc ModelASchedClasses[] = { ... InstA, 0, ... InstB, -1,... }; llvm::MCSchedClassDesc ModelBSchedClasses[] = { ... InstA, -1,... InstB, 0,... }; The -1 means invalid num of macro ops, while it is valid if it is >=0. This is what we look like now: llvm::MCSchedClassDesc ModelASchedClasses[] = { ... InstA, 0, ... InstB, 0,... }; llvm::MCSchedClassDesc ModelBSchedClasses[] = { ... InstA, 0,... InstB, 0,... }; And compiler hit the assertion here because the SCDesc is valid now for both InstA and InstB. Differential Revision: https://reviews.llvm.org/D67950 llvm-svn: 374524
* [TableGen] Support encoding per-HwModeJames Molloy2019-09-191-0/+3
| | | | | | | | | | | | | | Much like ValueTypeByHwMode/RegInfoByHwMode, this patch allows targets to modify an instruction's encoding based on HwMode. When the EncodingInfos field is non-empty the Inst and Size fields of the Instruction are ignored and taken from EncodingInfos instead. As part of this promote getHwMode() from TargetSubtargetInfo to MCSubtargetInfo. This is NFC for all existing targets - new code is generated only if targets use EncodingByHwMode. llvm-svn: 372320
* [TableGen] Correct comments for end of namespace. NFCBjorn Pettersson2019-08-251-2/+2
| | | | | | | | | | | | | | | | | | | | | | Summary: Update end-of-namespace comments generated by tablegen emitters to fulfill the rules setup by clang-tidy's llvm-namespace-comment checker. Fixed a few end-of-namespace comments in the tablegen source code as well. Reviewers: craig.topper Reviewed By: craig.topper Subscribers: craig.topper, stoklund, dschuff, sbc100, jgravelle-google, aheejin, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D66396 llvm-svn: 369865
* [WebAssembly] Merge used feature sets, update atomics linkage policyThomas Lively2019-03-291-1/+4
| | | | | | | | | | | | | | | | | | | | | | | | | Summary: It does not currently make sense to use WebAssembly features in some functions but not others, so this CL adds an IR pass that takes the union of all used feature sets and applies it to each function in the module. This allows us to prevent atomics from being lowered away if some function has opted in to using them. When atomics is not enabled anywhere, we detect whether there exists any atomic operations or thread local storage that would be stripped and disallow linking with objects that contain atomics if and only if atomics or tls are stripped. When atomics is enabled, mark it as used but do not require it of other objects in the link. These changes allow libraries that do not use atomics to be built once and linked into both single-threaded and multithreaded binaries. Reviewers: aheejin, sbc100, dschuff Subscribers: jgravelle-google, hiraditya, sunfish, jfb, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D59625 llvm-svn: 357226
* [Subtarget] Merge ProcSched and ProcDesc arrays in MCSubtargetInfo into a ↵Craig Topper2019-03-051-42/+11
| | | | | | | | | | | | single array. These arrays are both keyed by CPU name and go into the same tablegenerated file. Merge them so we only need to store keys once. This also removes a weird space saving quirk where we used the ProcDesc.size() to create to build an ArrayRef for ProcSched. Differential Revision: https://reviews.llvm.org/D58939 llvm-svn: 355431
* [Subtarget] Create a separate SubtargetSubtargetKV struct for ProcDesc to ↵Craig Topper2019-03-051-6/+4
| | | | | | | | | | | | remove fields from the stack tables that aren't needed for CPUs The description for CPUs was just the CPU name wrapped with "Select the " and " processor". We can just do that directly in the help printer instead of making a separate version in the binary for each CPU. Also remove the Value field that isn't needed and was always 0. Differential Revision: https://reviews.llvm.org/D58938 llvm-svn: 355429
* [Subtarget] Follow up to r355167, add another set of curly braces to ↵Craig Topper2019-03-041-2/+2
| | | | | | | | FeatureBitArray initialization to satisfy older versions of clang. Apparently older versions of clang like 3.6 require an extra set of curly braces around std::array initializations. I'm told the C++ language was changed regarding this by CWG 1270. llvm-svn: 355327
* [Subtarget] Remove static global constructor call from the tablegened ↵Craig Topper2019-03-011-21/+44
| | | | | | | | | | | | | | | | | | subtarget feature tables Subtarget features are stored in a std::bitset that has been subclassed. There is a special constructor to allow the tablegen files to provide a list of bits to initialize the std::bitset to. This constructor isn't constexpr and std::bitset doesn't support many constexpr operations either. This results in a static global constructor being used to initialize the feature bitsets in these files at startup. To fix this I've introduced a new FeatureBitArray class that holds three 64-bit values representing the initial bit values and taught tablegen to emit hex constants for them based on the feature enum values. This makes the tablegen files less readable than they were before. I can add the list of features back as a comment if we think that's important. I've added a method to convert from this class into the std::bitset subclass we had before. I considered making the new FeatureBitArray class just implement the std::bitset interface we need instead, but thought I'd see how others felts about that first. I've simplified the interfaces to SetImpliedBits and ClearImpliedBits a little minimize the number of times we need to convert to the bitset. This removes about 27K from my local release+asserts build of llc. Differential Revision: https://reviews.llvm.org/D58520 llvm-svn: 355167
* [MC] Make SubtargetFeatureKV only store one FeatureBitset and use an ↵Craig Topper2019-02-181-6/+6
| | | | | | | | | | | | 'unsigned' to hold the value. This class is used for two difference tablegen generated tables. For one of the tables the Value FeatureBitset only has one bit set. For the other usage the Implies field was unused. This patch changes the Value field to just be an unsigned. For the usage that put a real vector in bitset, we now use the previously unused Implies field and leave the Value field unused instead. This is good for a 16K reduction in the size of llc on my local build with all targets enabled. llvm-svn: 354243
* 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-0/+29
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* [TableGen] Emit more variant transitionsEvandro Menezes2018-11-231-2/+15
| | | | | | | | | | | | | | | | | | | | | | `llvm-mca` relies on the predicates to be based on `MCSchedPredicate` in order to resolve the scheduling for variant instructions. Otherwise, it aborts the building of the instruction model early. However, the scheduling model emitter in `TableGen` gives up too soon, unless all processors use only such predicates. In order to allow more processors to be used with `llvm-mca`, this patch emits scheduling transitions if any processor uses these predicates. The transition emitted for the processors using legacy predicates is the one specified with `NoSchedPred`, which is based on `MCSchedPredicate`. Preferably, `llvm-mca` should instead assume a reasonable default when a variant transition is not based on `MCSchedPredicate` for a given processor. This issue should be revisited in the future. Differential revision: https://reviews.llvm.org/D54648 llvm-svn: 347504
* [MCSched] Bind PFM Counters to the CPUs instead of the SchedModel.Clement Courbet2018-10-251-79/+7
| | | | | | | | | | | | | | | | 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-5/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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::sort(C.begin(), C.end(), ...) -> llvm::sort(C, ...)Fangrui Song2018-09-271-9/+8
| | | | | | | | | | | | Summary: The convenience wrapper in STLExtras is available since rL342102. Reviewers: dblaikie, javed.absar, JDevlieghere, andreadb Subscribers: MatzeB, sanjoy, arsenm, dschuff, mehdi_amini, sdardis, nemanjai, jvesely, nhaehnle, sbc100, jgravelle-google, eraman, aheejin, kbarton, JDevlieghere, javed.absar, gbedwell, jrtc27, mgrang, atanasyan, steven_wu, george.burgess.iv, dexonsmith, kristina, jsji, llvm-commits Differential Revision: https://reviews.llvm.org/D52573 llvm-svn: 343163
* [llvm-exegesis] Add support for measuring NumMicroOps.Clement Courbet2018-09-261-0/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* [TableGen][SubtargetEmitter] Add the ability for processor models to ↵Andrea Di Biagio2018-09-191-1/+44
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* [NFC] Update comments regarding BufferSize for ProcResources Jinsong Ji2018-09-181-1/+1
| | | | llvm-svn: 342491
* [Tablegen][MCInstPredicate] Removed redundant template argument from class ↵Andrea Di Biagio2018-08-141-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | 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
* [Tablegen] Replace uses of formatted_raw_ostream with raw_ostream in the ↵Andrea Di Biagio2018-08-131-17/+22
| | | | | | | | | | | | | | | | | | | | | | predicate expander. NFCI This is a follow-up of r339552. As pointed out by Craig in D50566, we don't need a formatted_raw_ostream to indent strings. We can use instead raw_ostream::indent(). Internally, class PredicateExpander already keeps track of the current indentation level. Also, the grammar for predicates is well parenthesized, and therefore we don't need to use a formatted_raw_ostream to continuously track the column number. Instead we can safely replace all the uses of formatted_raw_ostream::PadToColumn() with uses of raw_ostream::indent(). By replacing formatted_raw_ostream with a simpler raw_ostream, we also avoid the implicit check on the newline character on every print to stream. No functional change intended. llvm-svn: 339577
* [Tablegen][SubtargetEmitter] Improve expansion of predicates of a variant ↵Andrea Di Biagio2018-08-131-15/+39
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | scheduling class. This patch refactors the logic that expands predicates of a variant scheduling class. The idea is to improve the readability of the auto-generated code by removing redundant parentheses around predicate expressions, and by removing redundant if(true) statements. This patch replaces the definition of NoSchedPred in TargetSchedule.td with an instance of MCSchedPredicate. The new definition is sematically equivalent to the previous one. The main difference is that now SubtargetEmitter knows that it represents predicate "true". Before this patch, we always generated an if (true) for the default transition of a variant scheduling class. Example (taken from AArch64GenSubtargetInfo.inc) : ``` if (SchedModel->getProcessorID() == 3) { // CycloneModel if ((TII->isScaledAddr(*MI))) return 927; // (WriteIS_WriteLD)_ReadBaseRS if ((true)) return 928; // WriteLD_ReadDefault } ``` Extra parentheses were also generated around the predicate expressions. With this patch, we get the following auto-generated checks: ``` if (SchedModel->getProcessorID() == 3) { // CycloneModel if (TII->isScaledAddr(*MI)) return 927; // (WriteIS_WriteLD)_ReadBaseRS return 928; // WriteLD_ReadDefault } ``` The new auto-generated code behaves exactly the same as before. So, technically this is a non functional change. Differential revision: https://reviews.llvm.org/D50566 llvm-svn: 339552
* [Tablegen][SubtargetEmitter] refactor method `emitSchedModelHelpersImpl()`. NFCIAndrea Di Biagio2018-08-101-62/+96
| | | | | | | | | | Part of the logic has been moved to helper functions to (hopefully) improve readability. Added a few code comments to better describe how the algorithm works. No functional change intended. llvm-svn: 339421
* [TableGen] Emit a fatal error on inconsistencies in resource units vs cycles.Clement Courbet2018-06-131-2/+16
| | | | | | | | | | | | | | | | | | | | | Summary: For targets I'm not familiar with, I've automatically made the "default to 1 for each resource" behaviour explicit in the td files. For more obvious cases, I've ventured a fix. Some notes: - Exynos is especially fishy. - AArch64SchedThunderX2T99.td had some truncated entries. If I understand correctly, the person who wrote that interpreted the ResourceCycle as a range. I made the decision to use the upper/lower bound for consistency with the 'Latency' value. I'm sure there is a better choice. - The change to X86ScheduleBtVer2.td is an NFC, it just makes values more explicit. Also see PR37310. Reviewers: RKSimon, craig.topper, javed.absar Subscribers: kristof.beyls, llvm-commits Differential Revision: https://reviews.llvm.org/D46356 llvm-svn: 334586
* [MCSchedule] Add the ability to compute the latency and throughput ↵Andrea Di Biagio2018-05-311-3/+24
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | information for MCInst. This patch extends the MCSchedModel API with new methods that can be used to obtain the latency and reciprocal througput information for an MCInst. Scheduling models have recently gained the ability to resolve variant scheduling classes associated with MCInst objects. Before, models were only able to resolve a variant scheduling class from a MachineInstr object. This patch is mainly required by D47374 to avoid regressing a pair of x86 specific -print-schedule tests for btver2. Patch D47374 introduces a new variant class to teach the btver scheduling model (x86 target) how to correctly compute the latency profile for some zero-idioms using the new scheduling predicates. The new methods added by this patch would be mainly used by llc when flag -print-schedule is specified. In particular, tests that contain inline assembly require that code is parsed at code emission stage into a sequence of MCInst. That forces the print-schedule functionality to query the latency/rthroughput information for MCInst instructions too. If we don't expose this new API, then we lose "-print-schedule" test coverage as soon as variant scheduling classes are added to the x86 models. The tablegen SubtargetEmitter changes teaches how to query latency profile information using a object that derives from TargetSubtargetInfo. Note that this should really have been part of r333286. To avoid code duplication, the logic that "resolves" variant scheduling classes for MCInst, has been moved to a common place in MC. That logic is used by the "resolveVariantSchedClass" methods redefined in override by the tablegen'd GenSubtargetInfo classes. Differential Revision: https://reviews.llvm.org/D47536 llvm-svn: 333650
* [Tablegen] Avoid generating empty switch statements. NFCAndrea Di Biagio2018-05-271-4/+10
| | | | | | | This fixes an MSVC warning (warning C4065: switch statement contains 'default' but no 'case' labels) introduced with revision 333293. llvm-svn: 333363
* [Tablegen][SubtargetEmitter] Add a default case to the auto-generated switch ↵Andrea Di Biagio2018-05-251-1/+3
| | | | | | in MCSubtargetInfo::resolveVariantSchedClass(). NFC llvm-svn: 333293
* [RFC][Patch 2/3] Add a MCSubtargetInfo hook to resolve variant scheduling ↵Andrea Di Biagio2018-05-251-1/+24
| | | | | | | | | | | | | | | | | | | | classes. This patch is the second of a sequence of three patches related to LLVM-dev RFC "MC support for varinat scheduling classes". https://lists.llvm.org/pipermail/llvm-dev/2018-May/123181.html The goal of this patch is to enable the resolution of variant classes in MC with the help of a new method named `MCSubtargetInfo::resolveVariantSchedClass()`. This patch also teaches the SubtargetEmitter how to automatically generate the definition of method resolveVariantSchedClass(). That definition is emitted within a sub-class of MCSubtargetInfo named XXXGenMCSubtargetInfo (where XXX is the name of the Target). Differential Revision: https://reviews.llvm.org/D47077 llvm-svn: 333286
* [RFC][Patch 1/3] Add a new class of predicates for variant scheduling classes.Andrea Di Biagio2018-05-251-30/+76
| | | | | | | | | | | | | | | | | | | | | | This patch is the first of a sequence of three patches described by the LLVM-dev RFC "MC support for variant scheduling classes". http://lists.llvm.org/pipermail/llvm-dev/2018-May/123181.html The goal of this patch is to introduce a new class of scheduling predicates for SchedReadVariant and SchedWriteVariant. An MCSchedPredicate can be used instead of a normal SchedPredicate to model checks on the instruction (either a MachineInstr or a MCInst). Internally, an MCSchedPredicate encapsulates an MCInstPredicate definition. MCInstPredicate allows the definition of expressions with a well-known semantic, that can be used to generate code for both MachineInstr and MCInst. This is the first step toward teaching to tools like lllvm-mca how to resolve variant scheduling classes. Differential Revision: https://reviews.llvm.org/D46695 llvm-svn: 333282
* Rename DEBUG macro to LLVM_DEBUG.Nicola Zaghen2018-05-141-6/+7
| | | | | | | | | | | | | | | | The DEBUG() macro is very generic so it might clash with other projects. The renaming was done as follows: - git grep -l 'DEBUG' | xargs sed -i 's/\bDEBUG\s\?(/LLVM_DEBUG(/g' - git diff -U0 master | ../clang/tools/clang-format/clang-format-diff.py -i -p1 -style LLVM - Manual change to APInt - Manually chage DOCS as regex doesn't match it. In the transition period the DEBUG() macro is still present and aliased to the LLVM_DEBUG() one. Differential Revision: https://reviews.llvm.org/D43624 llvm-svn: 332240
* [Tablegen] SubtargetEmitter: move the logic that prints predicates for ↵Andrea Di Biagio2018-04-261-21/+47
| | | | | | variant scheduling classes to helper functions. NFC llvm-svn: 330968
* [llvm-exegesis] Fix PfmIssueCountersTable creationSimon Pilgrim2018-04-191-6/+11
| | | | | | | | | | | | | | This patch ensures that the pfm issue counter tables are the correct size, accounting for the invalid resource entry at the beginning of the resource tables. It also fixes an issue with pfm failing to match event counters due to a trailing comma added to all the event names. I've also added a counter comment to each entry as it helps locate problems with the tables. Note: I don't have access to a SandyBridge test machine, which is the only model to make use of multiple event counters being mapped to a single resource. I don't know if pfm accepts a comma-seperated list or not, but that is what it was doing. Differential Revision: https://reviews.llvm.org/D45787 llvm-svn: 330317
* [MC][TableGen] Fix r329675.Clement Courbet2018-04-101-4/+6
| | | | | | Caught by bots with -Wmissing-braces. llvm-svn: 329676
* [MC][TableGen] Add optional libpfm counter names for ProcResUnits.Clement Courbet2018-04-101-3/+59
| | | | | | | | | | | | | | | | 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
* [TableGen] Change std::sort to llvm::sort in response to r327219Mandeep Singh Grang2018-04-061-9/+9
| | | | | | | | | | | | | | | | | | | | | | Summary: r327219 added wrappers to std::sort which randomly shuffle the container before sorting. This will help in uncovering non-determinism caused due to undefined sorting order of objects having the same key. To make use of that infrastructure we need to invoke llvm::sort instead of std::sort. Note: This patch is one of a series of patches to replace *all* std::sort to llvm::sort. Refer the comments section in D44363 for a list of all the required patches. Reviewers: stoklund, kparzysz, dsanders Reviewed By: dsanders Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D45144 llvm-svn: 329451
* Fix the buildbots after r329304.Andrea Di Biagio2018-04-051-1/+1
| | | | llvm-svn: 329306
* [MC][Tablegen] Allow models to describe the retire control unit for llvm-mca. Andrea Di Biagio2018-04-051-0/+17
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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] Fix spaces between values printed by EmitRegisterFileInfo.Andrea Di Biagio2018-04-051-2/+2
| | | | llvm-svn: 329284
* [Tablegen] Slightly refactor method SubtargetEmitter::EmitExtraProcessorInfo.Andrea Di Biagio2018-04-041-10/+41
| | | | | | | This patch moves most of the logic from EmitExtraProcessorInfo to a couple of helper functions. No functional change intended. llvm-svn: 329173
* [MC][Tablegen] Allow the definition of processor register files in the ↵Andrea Di Biagio2018-04-031-2/+65
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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] Don't capture returned std::vectors by const reference.Craig Topper2018-03-231-12/+8
| | | | | | The full vector is being returned not a reference. So the reference was just a to a temporary. llvm-svn: 328275
* Fix some user facing typosSylvestre Ledru2018-03-171-2/+2
| | | | llvm-svn: 327776
* [MCSchedule] Always generate processor resource names.Andrea Di Biagio2018-03-081-2/+2
| | | | | | | | | | | | With this patch, the tablegen 'SubtargetEmitter' always generates processor resource names. The impact of this patch on the code size of other llvm tools is small. I have observed an average increase of 0.03% in code size when doing a release build of LLVM (on windows, using MSVC) with all the default backends. This change is done in preparation for the upcoming llvm-mca patch. llvm-svn: 326993
* Shrink various scheduling tables by using narrower types.Benjamin Kramer2018-02-231-7/+12
| | | | | | 16 bits ought to be enough for everyone. This shrinks clang by ~1MB. llvm-svn: 325941
* [TargetSchedule] Fix r324582.Clement Courbet2018-02-091-1/+1
| | | | | | | Increment was using the wrong NumUnits (the one from the ProcResGroup and not the subunit). llvm-svn: 324727
* Fix missing field initializer warning in TableGen SubtargetEmitterDavid Blaikie2018-02-081-3/+4
| | | | llvm-svn: 324643
* [TargetSchedule] Expose sub-units of a ProcResGroup in MCProcResourceDesc.Clement Courbet2018-02-081-3/+39
| | | | | | | | | | | | | | | | | | Summary: Right now using a ProcResource automatically counts as usage of all super ProcResGroups. All this is done during codegen, so there is no way for schedulers to get this information at runtime. This adds the information of which individual ProcRes units are contained in a ProcResGroup in MCProcResourceDesc. Reviewers: gchatelet Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D43023 llvm-svn: 324582
* [TableGen] Improve error reportingEvandro Menezes2017-11-211-4/+6
| | | | | | | | | 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
* [TableGen] Use Twine instead of std::string concatenation in two calls to ↵Craig Topper2017-10-261-4/+4
| | | | | | PrintFatalError. llvm-svn: 316697
* [TableGen] Fix some formatting quirks in the subtarget output file.Craig Topper2017-10-241-4/+5
| | | | llvm-svn: 316450
* [TableGen] Simplify some of the subtarget emission by removing code that ↵Craig Topper2017-10-241-45/+11
| | | | | | | | avoids printing commas at the end of arrays and enums. The C++ standard allows for trailing commas. We already do this in many other emitters. llvm-svn: 316449
OpenPOWER on IntegriCloud