summaryrefslogtreecommitdiffstats
path: root/llvm/lib/MC/MCSubtargetInfo.cpp
Commit message (Collapse)AuthorAgeFilesLines
* [System Model] [TTI] Update cache and prefetch TTI interfacesDavid Greene2019-10-091-0/+25
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Re-apply 9fdfb045ae8b/r365676 with fixes for PPC and Hexagon. This involved moving defaults from TargetTransformInfoImplBase to MCSubtargetInfo. Rework the TTI cache and software prefetching APIs to prepare for the introduction of a general system model. Changes include: - Marking existing interfaces const and/or override as appropriate - Adding comments - Adding BasicTTIImpl interfaces that delegate to a subtarget implementation - Moving the default TargetTransformInfoImplBase implementation to a default MCSubtarget implementation Only a handful of targets use these interfaces currently: AArch64, Hexagon, PPC and SystemZ. AArch64 already has a custom subtarget implementation, so its custom TTI implementation is migrated to use the new facilities in BasicTTIImpl to invoke its custom subtarget implementation. The custom TTI implementations continue to exist for the other targets with this change. They are not moved over to subtarget-based implementations. The end goal is to have the default subtarget implementation defer to the system model defined by the target. With this change, the default MCSubtargetInfo implementation essentially returns the defaults TargetTransformInfoImplBase used to return. Existing users of TTI defaults will hit the defaults now in MCSubtargetInfo. Targets that define their own custom TTI implementations won't use the BasicTTIImpl implementations that route to the subtarget. Once system models are in place for the targets that use these interfaces, their custom TTI implementations can be removed. Differential Revision: https://reviews.llvm.org/D63614 llvm-svn: 374205
* Revert "[System Model] [TTI] Update cache and prefetch TTI interfaces"David Greene2019-07-101-25/+0
| | | | | | | | This broke some PPC prefetching tests. This reverts commit 9fdfb045ae8bb643ab0d0455dcf9ecaea3b1eb3c. llvm-svn: 365680
* [System Model] [TTI] Update cache and prefetch TTI interfacesDavid Greene2019-07-101-0/+25
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Rework the TTI cache and software prefetching APIs to prepare for the introduction of a general system model. Changes include: - Marking existing interfaces const and/or override as appropriate - Adding comments - Adding BasicTTIImpl interfaces that delegate to a subtarget implementation - Adding a default "no information" subtarget implementation Only a handful of targets use these interfaces currently: AArch64, Hexagon, PPC and SystemZ. AArch64 already has a custom subtarget implementation, so its custom TTI implementation is migrated to use the new facilities in BasicTTIImpl to invoke its custom subtarget implementation. The custom TTI implementations continue to exist for the other targets with this change. They are not moved over to subtarget-based implementations. The end goal is to have the default subtarget implementation defer to the system model defined by the target. With this change, the default subtarget implementation essentially returns "no information" for these interfaces. None of the existing users of TTI will hit that implementation because they define their own custom TTI implementations and won't use the BasicTTIImpl implementations. Once system models are in place for the targets that use these interfaces, their custom TTI implementations can be removed. Differential Revision: https://reviews.llvm.org/D63614 llvm-svn: 365676
* Simplify std::lower_bound with llvm::{bsearch,lower_bound}. NFCFangrui Song2019-06-211-1/+1
| | | | llvm-svn: 364006
* Add --print-supported-cpus flag for clang.Ziang Wan2019-06-141-1/+34
| | | | | | | | | | | | This patch allows clang users to print out a list of supported CPU models using clang [--target=<target triple>] --print-supported-cpus Then, users can select the CPU model to compile to using clang --target=<triple> -mcpu=<model> a.c It is a handy feature to help cross compilation. llvm-svn: 363464
* [ARM] Replace fp-only-sp and d16 with fp64 and d32.Simon Tatham2019-05-281-0/+17
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Those two subtarget features were awkward because their semantics are reversed: each one indicates the _lack_ of support for something in the architecture, rather than the presence. As a consequence, you don't get the behavior you want if you combine two sets of feature bits. Each SubtargetFeature for an FP architecture version now comes in four versions, one for each combination of those options. So you can still say (for example) '+vfp2' in a feature string and it will mean what it's always meant, but there's a new string '+vfp2d16sp' meaning the version without those extra options. A lot of this change is just mechanically replacing positive checks for the old features with negative checks for the new ones. But one more interesting change is that I've rearranged getFPUFeatures() so that the main FPU feature is appended to the output list *before* rather than after the features derived from the Restriction field, so that -fp64 and -d32 can override defaults added by the main feature. Reviewers: dmgreen, samparker, SjoerdMeijer Subscribers: srhines, javed.absar, eraman, kristof.beyls, hiraditya, zzheng, Petar.Avramovic, cfe-commits, llvm-commits Tags: #clang, #llvm Differential Revision: https://reviews.llvm.org/D60691 llvm-svn: 361845
* [Subtarget] Merge ProcSched and ProcDesc arrays in MCSubtargetInfo into a ↵Craig Topper2019-03-051-12/+8
| | | | | | | | | | | | 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-8/+10
| | | | | | | | | | | | 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] Move SubtargetFeatureKV/SubtargetInfoKV from SubtargetFeature.h ↵Craig Topper2019-03-051-6/+159
| | | | | | | | | | | | | | | | to MCSubtargetInfo.h. Move all code that operates on ProcFeatures and ProcDesc arrays to MCSubtargetInfo. The SubtargetFeature class managed a list of features as strings. And it also had functions for setting bits in a FeatureBitset. The methods that operated on the Feature list as strings are used in other parts of the backend. But the parts that operate on FeatureBitset are very tightly coupled to MCSubtargetInfo and requires passing in the arrays that MCSubtargetInfo owns. And the same struct type is used for ProcFeatures and ProcDesc. This has led to MCSubtargetInfo having 2 arrays keyed by CPU name. One containing a mapping from a CPU name to its features. And one containing a mapping from CPU name to its scheduler model. I would like to make a single CPU array containing all CPU information and remove some unneeded fields the ProcDesc array currently has. But I don't want to make SubtargetFeatures.h have to know about the scheduler model type and have to forward declare or pull in the header file. Differential Revision: https://reviews.llvm.org/D58937 llvm-svn: 355428
* [SubtargetFeatures] Add operator< for comparing SubtargetInfoKV objects. NFCICraig Topper2019-03-041-4/+1
| | | | | | Use instead of passing a lambda to std::is_sorted. This is more consistent with SubtargetFeatureKV. llvm-svn: 355300
* 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
* [MC] fix documentation comments; NFCSanjay Patel2018-03-221-5/+0
| | | | llvm-svn: 328205
* Typo: const MCSchedModel SchedModel -> const MCSchedModel &SchedModelKrzysztof Parzyszek2017-09-271-1/+1
| | | | llvm-svn: 314301
* Subtarget support for parameterized register class informationKrzysztof Parzyszek2017-09-141-0/+12
| | | | | | | | Implement "checkFeatures" and emitting HW mode check code. Differential Revision: https://reviews.llvm.org/D31959 llvm-svn: 313295
* Sort the remaining #include lines in include/... and lib/....Chandler Carruth2017-06-061-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | I did this a long time ago with a janky python script, but now clang-format has built-in support for this. I fed clang-format every line with a #include and let it re-sort things according to the precise LLVM rules for include ordering baked into clang-format these days. I've reverted a number of files where the results of sorting includes isn't healthy. Either places where we have legacy code relying on particular include ordering (where possible, I'll fix these separately) or where we have particular formatting around #include lines that I didn't want to disturb in this patch. This patch is *entirely* mechanical. If you get merge conflicts or anything, just ignore the changes in this patch and run clang-format over your #include lines in the files. Sorry for any noise here, but it is important to keep these things stable. I was seeing an increasing number of patches with irrelevant re-ordering of #include lines because clang-format was used. This patch at least isolates that churn, makes it easy to skip when resolving conflicts, and gets us to a clean baseline (again). llvm-svn: 304787
* [MC] Fix some Clang-tidy modernize and Include What You Use warnings; other ↵Eugene Zelenko2017-02-081-3/+6
| | | | | | minor fixes (NFC). llvm-svn: 294526
* (NFC) Change SubtargetFeatures::ToggleFeature andArtyom Skrobov2016-01-051-4/+2
| | | | | | | | | | | SubtargetFeatures::ApplyFeatureFlag to be static, so that MCSubtargetInfo doesn't need to instantiate SubtargetFeatures for nothing. Also change the return type to void, as it wasn't ever used. This is a partial commit of http://reviews.llvm.org/D15746 llvm-svn: 256823
* Use an ArrayRef to simplify repeated calculation of the array end. NFCCraig Topper2016-01-031-5/+6
| | | | llvm-svn: 256702
* [ARM] Introduce subtarget features per ARM architecture.Bradley Smith2015-11-161-2/+2
| | | | | | | This allows for accurate architecture targeting as well as removing duplicate information (hardcoded feature strings) from MCTargetDesc. llvm-svn: 253196
* Use std::begin/end and std::is_sorted to simplify some code. NFCCraig Topper2015-10-171-7/+6
| | | | llvm-svn: 250614
* Revert r247692: Replace Triple with a new TargetTuple in MCTargetDesc/* and ↵Daniel Sanders2015-09-151-3/+3
| | | | | | | | related. NFC. Eric has replied and has demanded the patch be reverted. llvm-svn: 247702
* Re-commit r247683: Replace Triple with a new TargetTuple in MCTargetDesc/* ↵Daniel Sanders2015-09-151-3/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | and related. NFC. Summary: This is the first patch in the series to migrate Triple's (which are ambiguous) to TargetTuple's (which aren't). For the moment, TargetTuple simply passes all requests to the Triple object it holds. Once it has replaced Triple, it will start to implement the interface in a more suitable way. This change makes some changes to the public C++ API. In particular, InitMCSubtargetInfo(), createMCRelocationInfo(), and createMCSymbolizer() now take TargetTuples instead of Triples. The other public C++ API's have been left as-is for the moment to reduce patch size. This commit also contains a trivial patch to clang to account for the C++ API change. Thanks go to Pavel Labath for fixing LLDB for me. Reviewers: rengolin Subscribers: jyknight, dschuff, arsenm, rampitec, danalbert, srhines, javed.absar, dsanders, echristo, emaste, jholewinski, tberghammer, ted, jfb, llvm-commits, rengolin Differential Revision: http://reviews.llvm.org/D10969 llvm-svn: 247692
* Revert r247684 - Replace Triple with a new TargetTuple ...Daniel Sanders2015-09-151-3/+3
| | | | | | LLDB needs to be updated in the same commit. llvm-svn: 247686
* Replace Triple with a new TargetTuple in MCTargetDesc/* and related. NFC.Daniel Sanders2015-09-151-3/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | Summary: This is the first patch in the series to migrate Triple's (which are ambiguous) to TargetTuple's (which aren't). For the moment, TargetTuple simply passes all requests to the Triple object it holds. Once it has replaced Triple, it will start to implement the interface in a more suitable way. This change makes some changes to the public C++ API. In particular, InitMCSubtargetInfo(), createMCRelocationInfo(), and createMCSymbolizer() now take TargetTuples instead of Triples. The other public C++ API's have been left as-is for the moment to reduce patch size. This commit also contains a trivial patch to clang to account for the C++ API change. Reviewers: rengolin Subscribers: jyknight, dschuff, arsenm, rampitec, danalbert, srhines, javed.absar, dsanders, echristo, emaste, jholewinski, tberghammer, ted, jfb, llvm-commits, rengolin Differential Revision: http://reviews.llvm.org/D10969 llvm-svn: 247683
* MC: Only allow changing feature bits in MCSubtargetInfoDuncan P. N. Exon Smith2015-07-101-5/+12
| | | | | | | | | | | | | | | | | Disallow all mutation of `MCSubtargetInfo` expect the feature bits. Besides deleting the assignment operators -- which were dead "code" -- this restricts `InitMCProcessorInfo()` to subclass initialization sequences, and exposes a new more limited function called `setDefaultFeatures()` for use by the ARMAsmParser `.cpu` directive. There's a small functional change here: ARMAsmParser used to adjust `MCSubtargetInfo::CPUSchedModel` as a side effect of calling `InitMCProcessorInfo()`, but I've removed that suspicious behaviour. Since the AsmParser shouldn't be doing any scheduling, there shouldn't be any observable change... llvm-svn: 241961
* MC: Remove MCSubtargetInfo() default constructorDuncan P. N. Exon Smith2015-07-101-15/+5
| | | | | | | | | | | | | | | | | | | | | Force all creators of `MCSubtargetInfo` to immediately initialize it, merging the default constructor and the initializer into an initializing constructor. Besides cleaning up the code a little, this makes it clear that the initializer is never called again later. Out-of-tree backends need a trivial change: instead of calling: auto *X = new MCSubtargetInfo(); InitXYZMCSubtargetInfo(X, ...); return X; they should call: return createXYZMCSubtargetInfoImpl(...); There's no real functionality change here. llvm-svn: 241957
* MC: Remove MCSubtargetInfo::InitCPUSched()Duncan P. N. Exon Smith2015-07-101-5/+0
| | | | | | | | | | | | Remove all calls to `MCSubtargetInfo::InitCPUSched()` and merge its body into the only relevant caller, `MCSubtargetInfo::InitMCProcessorInfo()`. We were only calling the former after explicitly calling the latter with the same CPU; it's confusing to have both methods exposed. Besides a minor (surely unmeasurable) speedup in ARM and X86 from avoiding running the logic twice, no functionality change. llvm-svn: 241956
* MC: Remove the copy of MCSchedModel in MCSubtargetInfoDuncan P. N. Exon Smith2015-07-101-6/+5
| | | | | | | | | | | `MCSchedModel` is large. Make `MCSchedModel::GetDefaultSchedModel()` return by-reference instead of by-value, so we can store a pointer in `MCSubtargetInfo::CPUSchedModel` instead of a copy. Note: since `MCSchedModel` is POD, this doesn't create a static constructor. llvm-svn: 241947
* Replace string GNU Triples with llvm::Triple in MCSubtargetInfo and ↵Daniel Sanders2015-06-101-11/+6
| | | | | | | | | | | | | | | | | | create*MCSubtargetInfo(). NFC. Summary: This continues the patch series to eliminate StringRef forms of GNU triples from the internals of LLVM that began in r239036. Reviewers: rafael Reviewed By: rafael Subscribers: rafael, ted, jfb, llvm-commits, rengolin, jholewinski Differential Revision: http://reviews.llvm.org/D10311 llvm-svn: 239467
* [ARM] Add knowledge of FPU subtarget features to TargetParserJohn Brawn2015-06-051-0/+5
| | | | | | | | | | | | | Add getFPUFeatures to TargetParser, which gets the list of subtarget features that are enabled/disabled for each FPU, and use it when handling the .fpu directive. No functional change in this commit, though clang will start behaving differently once it starts using this. Differential Revision: http://reviews.llvm.org/D10237 llvm-svn: 239150
* Use std::bitset for SubtargetFeatures.Michael Kuperstein2015-05-261-2/+7
| | | | | | | | | | | | Previously, subtarget features were a bitfield with the underlying type being uint64_t. Since several targets (X86 and ARM, in particular) have hit or were very close to hitting this bound, switching the features to use a bitset. No functional change. The first several times this was committed (e.g. r229831, r233055), it caused several buildbot failures. Apparently the reason for most failures was both clang and gcc's inability to deal with large numbers (> 10K) of bitset constructor calls in tablegen-generated initializers of instruction info tables. This should now be fixed. llvm-svn: 238192
* Reverting r237234, "Use std::bitset for SubtargetFeatures"Michael Kuperstein2015-05-131-7/+2
| | | | | | | The buildbots are still not satisfied. MIPS and ARM are failing (even though at least MIPS was expected to pass). llvm-svn: 237245
* Use std::bitset for SubtargetFeaturesMichael Kuperstein2015-05-131-2/+7
| | | | | | | | | | | Previously, subtarget features were a bitfield with the underlying type being uint64_t. Since several targets (X86 and ARM, in particular) have hit or were very close to hitting this bound, switching the features to use a bitset. No functional change. The first two times this was committed (r229831, r233055), it caused several buildbot failures. At least some of the ARM and MIPS ones were due to gcc/binutils issues, and should now be fixed. llvm-svn: 237234
* Don't print an error message when looking up the scheduling model if user ↵Craig Topper2015-04-021-3/+4
| | | | | | specified -mcpu=help. llvm-svn: 233884
* Revert "Use std::bitset for SubtargetFeatures"Michael Kuperstein2015-03-241-7/+2
| | | | | | | | This reverts commit r233055. It still causes buildbot failures (gcc running out of memory on several platforms, and a self-host failure on arm), although less than the previous time. llvm-svn: 233068
* Use std::bitset for SubtargetFeaturesMichael Kuperstein2015-03-241-2/+7
| | | | | | | | | | | | | Previously, subtarget features were a bitfield with the underlying type being uint64_t. Since several targets (X86 and ARM, in particular) have hit or were very close to hitting this bound, switching the features to use a bitset. No functional change. The first time this was committed (r229831), it caused several buildbot failures. At least some of the ARM ones were due to gcc/binutils issues, and should now be fixed. Differential Revision: http://reviews.llvm.org/D8542 llvm-svn: 233055
* Reverting r229831 due to multiple ARM/PPC/MIPS build-bot failures.Michael Kuperstein2015-02-191-7/+2
| | | | llvm-svn: 229841
* Use std::bitset for SubtargetFeaturesMichael Kuperstein2015-02-191-2/+7
| | | | | | | | | | | Previously, subtarget features were a bitfield with the underlying type being uint64_t. Since several targets (X86 and ARM, in particular) have hit or were very close to hitting this bound, switching the features to use a bitset. No functional change. Differential Revision: http://reviews.llvm.org/D7065 llvm-svn: 229831
* Store the passed in CPU name string so that it can be accessed later.Eric Christopher2015-01-261-1/+2
| | | | llvm-svn: 227101
* Change MCSchedModel to be a struct of statically initialized data.Pete Cooper2014-09-021-7/+5
| | | | | | | | This removes static initializers from the backends which generate this data, and also makes this struct match the other Tablegen generated structs in behaviour Reviewed by Andy Trick and Chandler C llvm-svn: 216919
* ArrayRef-ize the Feature and Processor tables for SubtargetFeatures.Eric Christopher2014-05-061-11/+6
| | | | | | | | This removes arguments passed everywhere and allows the use of standard iteration over lists. Should be no functional change. llvm-svn: 208127
* Reverting r199886 (Prevent repetitive warnings for unrecognized processors ↵Artyom Skrobov2014-01-251-4/+7
| | | | | | and features) llvm-svn: 200083
* Prevent repetitive warnings for unrecognized processors and featuresArtyom Skrobov2014-01-231-7/+4
| | | | llvm-svn: 199886
* MC: Don't assume incoming StringRef's are null terminated.Will Dietz2013-10-131-3/+1
| | | | | | | | | | This can happen when processing command line arguments, which are often stored as std::string's and later turned into StringRef's via std::string::data(). Unfortunately this is not guaranteed to return a null-terminated string until C++11, causing breakage on platforms that don't do this. llvm-svn: 192558
* Fix X86 subtarget to not overwrite the autodetected features by calling ↵Craig Topper2013-09-181-0/+5
| | | | | | InitMCProcessorInfo right after detecting them. Instead add a new function that only updates the scheduling model and call that. llvm-svn: 190919
* Use the new script to sort the includes of every file under lib.Chandler Carruth2012-12-031-2/+2
| | | | | | | | | | | | | | | | | Sooooo many of these had incorrect or strange main module includes. I have manually inspected all of these, and fixed the main module include to be the nearest plausible thing I could find. If you own or care about any of these source files, I encourage you to take some time and check that these edits were sensible. I can't have broken anything (I strictly added headers, and reordered them, never removed), but they may not be the headers you'd really like to identify as containing the API being implemented. Many forward declarations and missing includes were added to a header files to allow them to parse cleanly when included first. The main module rule does in fact have its merits. =] llvm-svn: 169131
* Fix doxygen comment to match function name.Craig Topper2012-10-031-1/+1
| | | | llvm-svn: 165094
* Replaced ReInitMCSubtargetInfo with InitMCProcessor.Andrew Trick2012-09-181-14/+15
| | | | | | | | Now where we used to call ReInitMCSubtargetInfo, we actually recompute the same information as InitMCSubtargetInfo instead of only setting the feature bits. llvm-svn: 164105
* TargetSchedModel API. Implement latency lookup, disabled.Andrew Trick2012-09-181-1/+1
| | | | llvm-svn: 164098
* TableGen subtarget emitter. Initialize MCSubtargetInfo with the new machine ↵Andrew Trick2012-09-181-1/+9
| | | | | | model. llvm-svn: 164092
OpenPOWER on IntegriCloud