summaryrefslogtreecommitdiffstats
path: root/llvm/lib/MC/MCAsmBackend.cpp
Commit message (Collapse)AuthorAgeFilesLines
* [MC] Delete MCCodePadderFangrui Song2019-12-091-25/+1
| | | | | | | | | | | | | | | | | | | | | D34393 added MCCodePadder as an infrastructure for padding code with NOP instructions. It lacked tests and was not being worked on since then. Intel has now worked on an assembler patch to mitigate performance loss after applying microcode update for the Jump Conditional Code Erratum. https://www.intel.com/content/www/us/en/support/articles/000055650/processors.html This new patch shares similarity with MCCodePadder, but has a concrete use case in mind and is being actively developed. The infrastructure it introduces can potentially be used for general performance improvement via alignment. Delete the unused MCCodePadder so that people can develop the new feature from a clean state. Reviewed By: jyknight, skan Differential Revision: https://reviews.llvm.org/D71106
* [DebugInfo] Generate fixups as emitting DWARF .debug_frame/.eh_frame.Hsiangkai Wang2019-07-191-1/+4
| | | | | | | | | | | | | It is necessary to generate fixups in .debug_frame or .eh_frame as relaxation is enabled due to the address delta may be changed after relaxation. There is an opcode with 6-bits data in debug frame encoding. So, we also need 6-bits fixup types. Differential Revision: https://reviews.llvm.org/D58335 llvm-svn: 366524
* Revert "[DebugInfo] Generate fixups as emitting DWARF .debug_frame/.eh_frame."Hsiangkai Wang2019-07-181-4/+1
| | | | | | This reverts commit 17e3cbf5fe656483d9016d0ba9e1d0cd8629379e. llvm-svn: 366444
* [DebugInfo] Generate fixups as emitting DWARF .debug_frame/.eh_frame.Hsiangkai Wang2019-07-181-1/+4
| | | | | | | | | | | | | It is necessary to generate fixups in .debug_frame or .eh_frame as relaxation is enabled due to the address delta may be changed after relaxation. There is an opcode with 6-bits data in debug frame encoding. So, we also need 6-bits fixup types. Differential Revision: https://reviews.llvm.org/D58335 llvm-svn: 366442
* Boilerplate for producing XCOFF object files from the PowerPC backend.Sean Fertile2019-07-091-0/+4
| | | | | | | | | | Stubs out a number of the classes needed to produce a new object file format (XCOFF) for the powerpc-aix target. For testing input is an empty module which produces an object file with just a file header. Differential Revision: https://reviews.llvm.org/D61694 llvm-svn: 365541
* [ARM] Support .reloc *, R_ARM_NONE, *Fangrui Song2019-05-171-0/+1
| | | | | | | | | | | | | | | | R_ARM_NONE can be used to create references among sections. When --gc-sections is used, the referenced section will be retained if the origin section is retained. Add a generic MCFixupKind FK_NONE as this kind of no-op relocation is ubiquitous on ELF and COFF, and probably available on many other binary formats. See D62014. Reviewed By: peter.smith Differential Revision: https://reviews.llvm.org/D61992 llvm-svn: 360980
* 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
* [RISCV] Add symbol diff relocation support for RISC-VAlex Bradbury2018-05-231-1/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | For RISC-V it is desirable to have relaxation happen in the linker once addresses are known, and as such the size between two instructions/byte sequences in a section could change. For most assembler expressions, this is fine, as the absolute address results in the expression being converted to a fixup, and finally relocations. However, for expressions such as .quad .L2-.L1, the assembler folds this down to a constant once fragments are laid out, under the assumption that the difference can no longer change, although in the case of linker relaxation the differences can change at link time, so the constant is incorrect. One place where this commonly appears is in debug information, where the size of a function expression is in a form similar to the above. This patch extends the assembler to allow an AsmBackend to declare that it does not want the assembler to fold down this expression, and instead generate a pair of relocations that allow the linker to carry out the calculation. In this case, the expression is not folded, but when it comes to emitting a fixup, the generic FK_Data_* fixups are converted into a pair, one for the addition half, one for the subtraction, and this is passed to the relocation generating methods as usual. I have named these FK_Data_Add_* and FK_Data_Sub_* to indicate which half these are for. For RISC-V, which supports this via e.g. the R_RISCV_ADD64, R_RISCV_SUB64 pair of relocations, these are also set to always emit relocations relative to local symbols rather than section offsets. This is to deal with the fact that if relocations were calculated on e.g. .text+8 and .text+4, the result 12 would be stored rather than 4 as both addends are added in the linker. Differential Revision: https://reviews.llvm.org/D45181 Patch by Simon Cook. llvm-svn: 333079
* MC: Introduce an ELF dwo object writer and teach llvm-mc about it.Peter Collingbourne2018-05-211-0/+10
| | | | | | | | Part of PR37466. Differential Revision: https://reviews.llvm.org/D47051 llvm-svn: 332875
* MC: Separate creating a generic object writer from creating a target object ↵Peter Collingbourne2018-05-211-0/+26
| | | | | | | | | | | | | writer. NFCI. With this we gain a little flexibility in how the generic object writer is created. Part of PR37466. Differential Revision: https://reviews.llvm.org/D47045 llvm-svn: 332868
* MC: Change MCAsmBackend::writeNopData() to take a raw_ostream instead of an ↵Peter Collingbourne2018-05-211-4/+2
| | | | | | | | | | | | | MCObjectWriter. NFCI. To make this work I needed to add an endianness field to MCAsmBackend so that writeNopData() implementations know which endianness to use. Part of PR37466. Differential Revision: https://reviews.llvm.org/D47035 llvm-svn: 332857
* [RISCV] Add WasForced parameter to MCAsmBackend::fixupNeedsRelaxationAdvancedShiva Chen2018-05-181-2/+3
| | | | | | | | | | | | | | | | | | | | | | | | | For RISCV branch instructions, we need to preserve relocation types when linker relaxation enabled, so then linker could modify offset when the branch offsets changed. We preserve relocation types by define shouldForceRelocation. IsResolved return by evaluateFixup will always false when shouldForceRelocation return true. It will make RISCV MC Branch Relaxation always relax 16-bit branches to 32-bit form, even if the symbol actually could be resolved. To avoid 16-bit branches always relax to 32-bit form when linker relaxation enabled, we add a new parameter WasForced to indicate that the symbol actually couldn't be resolved and not forced by shouldForceRelocation return true. RISCVAsmBackend::fixupNeedsRelaxationAdvanced could relax branches with unresolved symbols by (!IsResolved && !WasForced). RISCV MC Branch Relaxation is needed because RISCV could perform 32-bit to 16-bit transformation in MC layer. Differential Revision: https://reviews.llvm.org/D46350 llvm-svn: 332696
* [MC] Adding code padding for performance stability - infrastructure. NFC.Omer Paparo Bivas2017-10-241-1/+27
| | | | | | | | | | | | | | | | | Infrastructure designed for padding code with nop instructions in key places such that preformance improvement will be achieved. The infrastructure is implemented such that the padding is done in the Assembler after the layout is done and all IPs and alignments are known. This patch by itself in a NFC. Future patches will make use of this infrastructure to implement required policies for code padding. Reviewers: aaboud zvi craig.topper gadi.haber Differential revision: https://reviews.llvm.org/D34393 Change-Id: I92110d0c0a757080a8405636914a93ef6f8ad00e llvm-svn: 316413
* 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-4/+9
| | | | | | minor fixes (NFC). llvm-svn: 294526
* [mips][ias] Support .dtprel[d]word and .tprel[d]word directivesSimon Atanasyan2016-08-221-0/+4
| | | | | | | | | | | | | Assembler directives .dtprelword, .dtpreldword, .tprelword, and .tpreldword generates relocations R_MIPS_TLS_DTPREL32, R_MIPS_TLS_DTPREL64, R_MIPS_TLS_TPREL32, and R_MIPS_TLS_TPREL64 respectively. The main motivation for this patch is to be able to write test cases for checking correctness of the LLD linker's behaviour. Differential Revision: https://reviews.llvm.org/D23669 llvm-svn: 279439
* MachO: enable .data_region directives everywhereTim Northover2016-04-211-1/+1
| | | | | | | | | | We'd disabled them on x86 because back in the early days some host tools couldn't handle the new load commands. This no longer holds: anyone capable of deploying Clang should be able to deploy its copies of ar/ranlib/etc. rdar://25254790 llvm-svn: 267075
* [MC, COFF] Add .reloc support for WinCOFFDavid Majnemer2016-01-191-2/+2
| | | | | | | This adds rudimentary support for a few relocations that we will use for the CodeView debug format. llvm-svn: 258216
* Implement .reloc (constant offset only) with support for R_MIPS_NONE and ↵Daniel Sanders2015-11-121-0/+4
| | | | | | | | | | | | | | | | R_MIPS_32. Summary: Support for R_MIPS_NONE allows us to parse MIPS16's usage of .reloc. R_MIPS_32 was included to be able to better test the directive. Targets can add their relocations by overriding MCAsmBackend::getFixupKind(). Subscribers: grosbach, rafael, majnemer, dsanders, llvm-commits Differential Revision: http://reviews.llvm.org/D13659 llvm-svn: 252888
* [MC] Allow backends to decide relaxation for unresolved fixups.Colin LeMahieu2015-05-301-19/+25
| | | | | | Differential Revision: http://reviews.llvm.org/D8217 llvm-svn: 238659
* Simplify a really complicated check for Arch == X86_64.Rafael Espindola2014-03-111-2/+1
| | | | | | | | | | | | The function hasReliableSymbolDifference had exactly one use in the MachO writer. It is also only true for X86_64. In fact, the comments refers to "Darwin x86_64" and everything else, so this makes the code match the comment. If this is to be abstracted again, it should be a property of TargetObjectWriter, like useAggressiveSymbolFolding. llvm-svn: 203605
* Use llvm::array_lengthof to replace sizeof(array)/sizeof(array[0]).Craig Topper2013-07-151-2/+2
| | | | llvm-svn: 186301
* MachO: direct-to-object attribute for data-in-code markers.Jim Grosbach2012-10-011-5/+2
| | | | | | | | | | The target backend can support data-in-code load commands even when the assembler doesn't, or vice-versa. Allow targets to opt-in for direct-to-object. PR13973. llvm-svn: 164974
* Tidy up. Trailing whitespace.Jim Grosbach2012-05-111-1/+1
| | | | llvm-svn: 156602
* Prune some includes and forward declarations.Craig Topper2012-03-261-0/+1
| | | | llvm-svn: 153429
* Section relative fixups are a coff concept, not a x86 one. Replace theRafael Espindola2011-12-241-1/+5
| | | | | | x86 specific reloc_coff_secrel32 with a generic FK_SecRel_4. llvm-svn: 147252
* This patch addresses gp relative fixups/relocations for jump tables.Akira Hatanaka2011-11-231-6/+10
| | | | llvm-svn: 145112
* Rename TargetAsmBackend to MCAsmBackend; rename createAsmBackend to ↵Evan Cheng2011-07-251-0/+37
createMCAsmBackend. llvm-svn: 136010
OpenPOWER on IntegriCloud