summaryrefslogtreecommitdiffstats
path: root/llvm/lib/Target/Mips/MCTargetDesc/MipsOptionRecord.cpp
Commit message (Collapse)AuthorAgeFilesLines
* [MCRegInfo] Add forward sub and super register iterators. (NFC)Florian Hahn2019-12-051-14/+10
| | | | | | | | | | | | | | | | | | | This patch adds forward iterators mc_difflist_iterator, mc_subreg_iterator and mc_superreg_iterator, based on the existing DiffListIterator. Those are used to provide iterator ranges over sub- and super-register from TRI, which are slightly more convenient than the existing MCSubRegIterator/MCSuperRegIterator. Unfortunately, it duplicates a bit of functionality, but the new iterators are a bit more convenient (and can be used with various existing iterator utilities) and should probably replace the old iterators in the future. This patch updates some existing users. Reviewers: evandro, qcolombet, paquette, MatzeB, arsenm Reviewed By: qcolombet Differential Revision: https://reviews.llvm.org/D70565
* [Alignment][NFC] Remove unneeded llvm:: scoping on Align typesGuillaume Chatelet2019-09-271-2/+2
| | | | llvm-svn: 373081
* [Alignment] Introduce llvm::Align to MCSectionGuillaume Chatelet2019-09-131-2/+2
| | | | | | | | | | | | | | | | | Summary: This is patch is part of a series to introduce an Alignment type. See this thread for context: http://lists.llvm.org/pipermail/llvm-dev/2019-July/133851.html See this patch for the introduction of the type: https://reviews.llvm.org/D64790 Reviewers: courbet, JDevlieghere Subscribers: arsenm, sdardis, jvesely, nhaehnle, sbc100, hiraditya, aheejin, jrtc27, atanasyan, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D67486 llvm-svn: 371831
* 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
* Move Object format code to lib/BinaryFormat.Zachary Turner2017-06-071-1/+1
| | | | | | | | | | | | This creates a new library called BinaryFormat that has all of the headers from llvm/Support containing structure and layout definitions for various types of binary formats like dwarf, coff, elf, etc as well as the code for identifying a file from its magic. Differential Revision: https://reviews.llvm.org/D33843 llvm-svn: 304864
* 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-141-2/+8
| | | | | | | | minor fixes (NFC). Same changes in files affected by reduced MC headers dependencies. llvm-svn: 295009
* [mips] Add COP0 register class and use it in M[FT]C0/DM[FT]C0.Daniel Sanders2015-06-271-0/+3
| | | | | | | | | | | | | | | | | Summary: Previously it (incorrectly) used GPR's. Patch by Simon Dardis. A couple small corrections by myself. Reviewers: dsanders Reviewed By: dsanders Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D10567 llvm-svn: 240883
* Replace getOrCreateSectionData with registerSection.Rafael Espindola2015-05-261-2/+2
| | | | | | There is now no SectionData to be created. llvm-svn: 238208
* Stop forwarding (get|set)Aligment from MCSectionData to MCSection.Rafael Espindola2015-05-211-3/+4
| | | | llvm-svn: 237956
* Move alignment from MCSectionData to MCSection.Rafael Espindola2015-05-211-3/+3
| | | | | | | | | | | | | | | | | | | | | | | | This starts merging MCSection and MCSectionData. There are a few issues with the current split between MCSection and MCSectionData. * It optimizes the the not as important case. We want the production of .o files to be really fast, but the split puts the information used for .o emission in a separate data structure. * The ELF/COFF/MachO hierarchy is not represented in MCSectionData, leading to some ad-hoc ways to represent the various flags. * It makes it harder to remember where each item is. The attached patch starts merging the two by moving the alignment from MCSectionData to MCSection. Most of the patch is actually just dropping 'const', since MCSectionData is mutable, but MCSection was not. llvm-svn: 237936
* [Mips] Add .MIPS.options section descriptor kinds enumerationSimon Atanasyan2015-02-161-1/+1
| | | | | | No functional changes. llvm-svn: 229452
* Re-sort #include lines using my handy dandy ./utils/sort_includes.pyChandler Carruth2015-02-131-1/+1
| | | | | | script. This is in preparation for changes to lots of include lines. llvm-svn: 229088
* Compute the ELF SectionKind from the flags.Rafael Espindola2015-01-291-5/+3
| | | | | | | | | | | | Any code creating an MCSectionELF knows ELF and already provides the flags. SectionKind is an abstraction used by common code that uses a plain MCSection. Use the flags to compute the SectionKind. This removes a lot of guessing and boilerplate from the MCSectionELF construction. llvm-svn: 227476
* Move the Mips target to storing the ABI in the TargetMachine ratherEric Christopher2015-01-261-4/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | than on MipsSubtargetInfo. This required a bit of massaging in the MC level to handle this since MC is a) largely a collection of disparate classes with no hierarchy, and b) there's no overarching equivalent to the TargetMachine, instead only the subtarget via MCSubtargetInfo (which is the base class of TargetSubtargetInfo). We're now storing the ABI in both the TargetMachine level and in the MC level because the AsmParser and the TargetStreamer both need to know what ABI we have to parse assembly and emit objects. The target streamer has a pointer to the one in the asm parser and is updated when the asm parser is created. This is fragile as the FIXME comment notes, but shouldn't be a problem in practice since we always create an asm parser before attempting to emit object code via the assembler. The TargetMachine now contains the ABI so that the DataLayout can be constructed dependent upon ABI. All testcases have been updated to use the -target-abi command line flag so that we can set the ABI without using a subtarget feature. Should be no change visible externally here. llvm-svn: 227102
* Reverted my "Testing commit access" commit.Toma Tabacu2014-08-121-0/+1
| | | | llvm-svn: 215441
* Testing commit access.Toma Tabacu2014-08-121-1/+0
| | | | llvm-svn: 215440
* [mips] Add MipsOptionRecord abstraction and use it to implement ↵Daniel Sanders2014-07-211-0/+92
.reginfo/.MIPS.options This abstraction allows us to support the various records that can be placed in the .MIPS.options section in the future. We currently use it to record register usage information (the ODK_REGINFO record in our ELF64 spec). Each .MIPS.options record should subclass MipsOptionRecord and provide an implementation of EmitMipsOptionRecord. Patch by Matheus Almeida and Toma Tabacu llvm-svn: 213522
OpenPOWER on IntegriCloud