summaryrefslogtreecommitdiffstats
path: root/llvm/lib/Target/TargetLoweringObjectFile.cpp
Commit message (Collapse)AuthorAgeFilesLines
* 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
* Add support for #pragma clang sectionJaved Absar2017-06-051-0/+14
| | | | | | | | | | | | | | | This patch provides a means to specify section-names for global variables, functions and static variables, using #pragma directives. This feature is only defined to work sensibly for ELF targets. One can specify section names as: #pragma clang section bss="myBSS" data="myData" rodata="myRodata" text="myText" One can "unspecify" a section name with empty string e.g. #pragma clang section bss="" data="" text="" rodata="" Reviewers: Roger Ferrer, Jonathan Roelofs, Reid Kleckner Differential Revision: https://reviews.llvm.org/D33413 llvm-svn: 304704
* Remove unnecessary conditions as suggested by clang-tidy. NFCGabor Horvath2017-05-011-1/+1
| | | | | | | | Patch by: Gergely Angeli! Differential Revision: https://reviews.llvm.org/D31936 llvm-svn: 301807
* [TargetLowering] Simplfiy a bit. NFCI.Davide Italiano2017-01-141-4/+1
| | | | llvm-svn: 292024
* CodeGen: simplify TargetMachine::getSymbol interface. NFC.Tim Northover2016-11-221-2/+2
| | | | | | | | | No-one actually had a mangler handy when calling this function, and getSymbol itself went most of the way towards getting its own mangler (with a local TLOF variable) so forcing all callers to supply one was just extra complication. llvm-svn: 287645
* Target: Change various section classifiers in TargetLoweringObjectFile to ↵Peter Collingbourne2016-10-241-8/+9
| | | | | | | | | | | | | | | | take a GlobalObject. These functions are about classifying a global which will actually be emitted, so it does not make sense for them to take a GlobalValue which may for example be an alias. Change the Mach-O object writer and the Hexagon, Lanai and MIPS backends to look through aliases before using TargetLoweringObjectFile interfaces. These are functional changes but all appear to be bug fixes. Differential Revision: https://reviews.llvm.org/D25917 llvm-svn: 285006
* Trying to fix Mangler memory leak in TargetLoweringObjectFile.Eric Liu2016-09-161-0/+2
| | | | | | | | | | | | | | Summary: `TargetLoweringObjectFile` can be re-used and thus `TargetLoweringObjectFile::Initialize()` can be called multiple times causing `Mang` pointer memory leak. Reviewers: echristo Subscribers: llvm-commits, mehdi_amini Differential Revision: https://reviews.llvm.org/D24659 llvm-svn: 281718
* Move the Mangler from the AsmPrinter down to TLOF and clean up theEric Christopher2016-09-161-19/+16
| | | | | | TLOF API accordingly. llvm-svn: 281708
* [ARM] Add support for embedded position-independent codeOliver Stannard2016-08-081-6/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch adds support for some new relocation models to the ARM backend: * Read-only position independence (ROPI): Code and read-only data is accessed PC-relative. The offsets between all code and RO data sections are known at static link time. This does not affect read-write data. * Read-write position independence (RWPI): Read-write data is accessed relative to the static base register (r9). The offsets between all writeable data sections are known at static link time. This does not affect read-only data. These two modes are independent (they specify how different objects should be addressed), so they can be used individually or together. They are otherwise the same as the "static" relocation model, and are not compatible with SysV-style PIC using a global offset table. These modes are normally used by bare-metal systems or systems with small real-time operating systems. They are designed to avoid the need for a dynamic linker, the only initialisation required is setting r9 to an appropriate value for RWPI code. I have only added support to SelectionDAG, not FastISel, because FastISel is currently disabled for bare-metal targets where these modes would be used. Differential Revision: https://reviews.llvm.org/D23195 llvm-svn: 278015
* Use isPositionIndependent(). NFC.Rafael Espindola2016-06-281-2/+1
| | | | llvm-svn: 274005
* Simplify. NFC.Rafael Espindola2016-06-241-10/+1
| | | | | | | Also delete out of date comment. This code was always returning .data since r253436. llvm-svn: 273739
* IR: Introduce local_unnamed_addr attribute.Peter Collingbourne2016-06-141-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | If a local_unnamed_addr attribute is attached to a global, the address is known to be insignificant within the module. It is distinct from the existing unnamed_addr attribute in that it only describes a local property of the module rather than a global property of the symbol. This attribute is intended to be used by the code generator and LTO to allow the linker to decide whether the global needs to be in the symbol table. It is possible to exclude a global from the symbol table if three things are true: - This attribute is present on every instance of the global (which means that the normal rule that the global must have a unique address can be broken without being observable by the program by performing comparisons against the global's address) - The global has linkonce_odr linkage (which means that each linkage unit must have its own copy of the global if it requires one, and the copy in each linkage unit must be the same) - It is a constant or a function (which means that the program cannot observe that the unique-address rule has been broken by writing to the global) Although this attribute could in principle be computed from the module contents, LTO clients (i.e. linkers) will normally need to be able to compute this property as part of symbol resolution, and it would be inefficient to materialize every module just to compute it. See: http://lists.llvm.org/pipermail/llvm-commits/Week-of-Mon-20160509/356401.html http://lists.llvm.org/pipermail/llvm-commits/Week-of-Mon-20160516/356738.html for earlier discussion. Part of the fix for PR27553. Differential Revision: http://reviews.llvm.org/D20348 llvm-svn: 272709
* Don't pass a Reloc::Model to MC.Rafael Espindola2016-05-181-1/+2
| | | | | | | | | | | | MC only needs to know if the output is PIC or not. It never has to decide about creating GOTs and PLTs for example. The only thing that MC itself uses this information for is expanding "macros" in sparc and mips. The rest I am pretty sure could be moved to CodeGen. This is a cleanup and isolates the code from future changes to Reloc::Model. llvm-svn: 269909
* [X86] Create mergeable constant pool entries for AVXDavid Majnemer2016-02-221-0/+1
| | | | | | | We supported creating mergeable constant pool entries for smaller constants but not for 32-byte AVX constants. llvm-svn: 261584
* [X86] Use the correct alignment for COMDAT constant pool entriesDavid Majnemer2016-02-211-2/+5
| | | | | | | | | | | | | | | | | | | COFF doesn't have sections with mergeable contents. Instead, each constant pool entry ends up in a COMDAT section. The linker, when choosing between COMDAT sections, doesn't choose the max alignment of the two sections. You just get whatever alignment was on the section. If one constant needed a higher alignment in one object file from another one, then we will get into trouble if the linker chooses the lower alignment one. Instead, lets promote the alignment of the constant pool entry to make sure we don't use an under aligned constant with an instruction which assumed otherwise. This fixes PR26680. llvm-svn: 261462
* Stop producing .data.rel sections.Rafael Espindola2015-11-181-3/+3
| | | | | | | | | | | | | | | | | If a section is rw, it is irrelevant if the dynamic linker will write to it or not. It looks like llvm implemented this because gcc was doing it. It looks like gcc implemented this in the hope that it would put all the relocated items close together and speed up the dynamic linker. There are two problem with this: * It doesn't work. Both bfd and gold will map .data.rel to .data and concatenate the input sections in the order they are seen. * If we want a feature like that, it can be implemented directly in the linker since it knowns where the dynamic relocations are. llvm-svn: 253436
* Drop prelink support.Rafael Espindola2015-11-171-25/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The way prelink used to work was * The compiler decides if a given section only has relocations that are know to point to the same DSO. If so, it names it .data.rel.ro.local<something>. * The static linker puts all of these together. * The prelinker program assigns addresses to each library and resolves the local relocations. There are many problems with this: * It is incompatible with address space randomization. * The information passed by the compiler is redundant. The linker knows if a given relocation is in the same DSO or not. If could sort by that if so desired. * There are newer ways of speeding up DSO (gnu hash for example). * Even if we want to implement this again in the compiler, the previous implementation is pretty broken. It talks about relocations that are "resolved by the static linker". If they are resolved, there are none left for the prelinker. What one needs to track is if an expression will require only dynamic relocations that point to the same DSO. At this point it looks like the prelinker is an historical curiosity. For example, fedora has retired it because it failed to build for two releases (http://pkgs.fedoraproject.org/cgit/prelink.git/commit/?id=eb43100a8331d91c801ee3dcdb0a0bb9babfdc1f) This patch removes support for it. That is, it stops printing the ".local" sections. llvm-svn: 253280
* CodeGen, Target: Move Mach-O-specific symbol name logic to Mach-O lowering.Peter Collingbourne2015-11-031-3/+3
| | | | | | | | | | | | | | | | | A profile of an LTO link of Chrome revealed that we were spending some ~30-50% of execution time in the function Constant::getRelocationInfo(), which is called from TargetLoweringObjectFile::getKindForGlobal() and in turn from TargetMachine::getNameWithPrefix(). It turns out that we only need the result of getKindForGlobal() when targeting Mach-O, so this change moves the relevant part of the logic to TargetLoweringObjectFileMachO. NFCI. Differential Revision: http://reviews.llvm.org/D14168 llvm-svn: 252014
* Remove DataLayout from TargetLoweringObjectFile, redirect to ModuleMehdi Amini2015-07-161-8/+7
| | | | | | | | | | | | | | | | Summary: This change is part of a series of commits dedicated to have a single DataLayout during compilation by using always the one owned by the module. Reviewers: echristo Subscribers: yaron.keren, rafael, llvm-commits, jholewinski Differential Revision: http://reviews.llvm.org/D11079 From: Mehdi Amini <mehdi.amini@apple.com> llvm-svn: 242385
* Clean up redundant copies of Triple objects. NFCDaniel Sanders2015-06-161-1/+1
| | | | | | | | | | | | | | Summary: Reviewers: rengolin Reviewed By: rengolin Subscribers: llvm-commits, rengolin, jholewinski Differential Revision: http://reviews.llvm.org/D10382 llvm-svn: 239823
* Recommit r239721: Replace string GNU Triples with llvm::Triple in ↵Daniel Sanders2015-06-161-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | InitMCObjectFileInfo. NFC. Summary: This affects other tools so the previous C++ API has been retained as a deprecated function for the moment. Clang has been updated with a trivial patch (not covered by the pre-commit review) to avoid breaking -Werror builds. Other in-tree tools will be fixed with similar patches. This continues the patch series to eliminate StringRef forms of GNU triples from the internals of LLVM that began in r239036. The first time this was committed it accidentally fixed an inconsistency in triples in llvm-mc and this caused a failure. This inconsistency was fixed in r239808. Reviewers: rengolin Reviewed By: rengolin Subscribers: llvm-commits, rengolin Differential Revision: http://reviews.llvm.org/D10366 llvm-svn: 239812
* Revert r239721 - Replace string GNU Triples with llvm::Triple in ↵Daniel Sanders2015-06-151-2/+2
| | | | | | | | InitMCObjectFileInfo. NFC. It appears to cause sparc-little-endian.s to assert on Windows and Darwin. llvm-svn: 239724
* Replace string GNU Triples with llvm::Triple in InitMCObjectFileInfo. NFC.Daniel Sanders2015-06-151-2/+2
| | | | | | | | | | | | | | | | | | | | | Summary: This affects other tools so the previous C++ API has been retained as a deprecated function for the moment. Clang has been updated with a trivial patch (not covered by the pre-commit review) to avoid breaking -Werror builds. Other in-tree tools will be fixed with similar trivial patches. This continues the patch series to eliminate StringRef forms of GNU triples from the internals of LLVM that began in r239036. Reviewers: rengolin Reviewed By: rengolin Subscribers: llvm-commits, rengolin Differential Revision: http://reviews.llvm.org/D10366 llvm-svn: 239721
* MC: Clean up MCExpr naming. NFC.Jim Grosbach2015-05-301-4/+4
| | | | llvm-svn: 238634
* Move alignment from MCSectionData to MCSection.Rafael Espindola2015-05-211-11/+11
| | | | | | | | | | | | | | | | | | | | | | | | 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
* MC: Clean up method names in MCContext.Jim Grosbach2015-05-181-2/+2
| | | | | | | The naming was a mish-mash of old and new style. Update to be consistent with the new. NFC. llvm-svn: 237594
* Remove superfluous .str() and replace std::string concatenation with Twine.Yaron Keren2015-03-271-1/+1
| | | | llvm-svn: 233392
* COFF: Let globals with private linkage reside in their own sectionDavid Majnemer2015-03-171-0/+6
| | | | | | | | | | COFF COMDATs (for selection kinds other than 'select any') require at least one non-section symbol in the symbol table. Satisfy this by morally enhancing the linkage from private to internal. Differential Revision: http://reviews.llvm.org/D8394 llvm-svn: 232570
* Revert "COFF: Let globals with private linkage reside in their own section"David Majnemer2015-03-171-6/+0
| | | | | | This reverts commit r232539. This was committed accidently. llvm-svn: 232543
* COFF: Let globals with private linkage reside in their own sectionDavid Majnemer2015-03-171-0/+6
| | | | | | | | | | | | | | | Summary: COFF COMDATs (for selection kinds other than 'select any') require at least one non-section symbol in the symbol table. Satisfy this by morally enhancing the linkage from private to internal. Reviewers: rafael Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D8374 llvm-svn: 232539
* Add r228939 back with a fix.Rafael Espindola2015-02-171-0/+18
| | | | | | | | | | | | | The problem in the original patch was not switching back to .text after printing an eh table. Original message: On ELF, put PIC jump tables in a non executable section. Fixes PR22558. llvm-svn: 229586
* Revert "On ELF, put PIC jump tables in a non executable section."Matthias Braun2015-02-141-18/+0
| | | | | | | | | This reverts commit r228939. The commit broke something in the output of exception handling tables on darwin x86-64. llvm-svn: 229203
* On ELF, put PIC jump tables in a non executable section.Rafael Espindola2015-02-121-0/+18
| | | | | | Fixes PR22558. llvm-svn: 228939
* Put each jump table in an independent section if the function is too.Rafael Espindola2015-02-121-0/+5
| | | | | | This allows the linker to GC both, fixing pr22557. llvm-svn: 228937
* Remove MergeableConst.Rafael Espindola2015-01-291-1/+2
| | | | | | | Only the specific ones (MergeableConst4, MergeableConst8, MergeableConst16) are handled specially. llvm-svn: 227440
* Move DataLayout back to the TargetMachine from TargetSubtargetInfoEric Christopher2015-01-261-3/+2
| | | | | | | | | | | | | | | | | | | derived classes. Since global data alignment, layout, and mangling is often based on the DataLayout, move it to the TargetMachine. This ensures that global data is going to be layed out and mangled consistently if the subtarget changes on a per function basis. Prior to this all targets(*) have had subtarget dependent code moved out and onto the TargetMachine. *One target hasn't been migrated as part of this change: R600. The R600 port has, as a subtarget feature, the size of pointers and this affects global data layout. I've currently hacked in a FIXME to enable progress, but the port needs to be updated to either pass the 64-bitness to the TargetMachine, or fix the DataLayout to avoid subtarget dependent features. llvm-svn: 227113
* Recommit r224935 with a fix for the ObjC++/AArch64 bug that that revisionLang Hames2015-01-091-6/+0
| | | | | | | | | | introduced. A test case for the bug was already committed in r225385. Patch by Rafael Espindola. llvm-svn: 225534
* Revert r224935 "Refactor duplicated code. No intended functionality change."Lang Hames2015-01-061-0/+6
| | | | | | | | This is affecting the behavior of some ObjC++ / AArch64 test cases on Darwin. Reverting to get the bots green while I track down the source of the changed behavior. llvm-svn: 225311
* Refactor duplicated code.Rafael Espindola2014-12-291-6/+0
| | | | | | No intended functionality change. llvm-svn: 224935
* Remove a bit of dead code.Rafael Espindola2014-11-121-19/+0
| | | | | | Every "real" object file implements this an ptx doesn't use it. llvm-svn: 221746
* Remove the TargetMachine forwards for TargetSubtargetInfo basedEric Christopher2014-08-041-2/+4
| | | | | | information and update all callers. No functional change. llvm-svn: 214781
* CodeGen: Stick constant pool entries in COMDAT sections for WinCOFFDavid Majnemer2014-07-141-1/+2
| | | | | | | | | | | | | | | | COFF lacks a feature that other object file formats support: mergeable sections. To work around this, MSVC sticks constant pool entries in special COMDAT sections so that each constant is in it's own section. This permits unused constants to be dropped and it also allows duplicate constants in different translation units to get merged together. This fixes PR20262. Differential Revision: http://reviews.llvm.org/D4482 llvm-svn: 213006
* Target: Replace getSection().empty() with hasSection()David Majnemer2014-05-171-1/+1
| | | | | | No functional change, just a small cleanup. llvm-svn: 209064
* [C++] Use 'nullptr'. Target edition.Craig Topper2014-04-251-4/+4
| | | | llvm-svn: 207197
* Target: whitespaceSaleem Abdulrasool2014-04-161-1/+1
| | | | llvm-svn: 206353
* [cleanup] Re-sort all the includes with utils/sort_includes.py.Chandler Carruth2014-03-041-1/+1
| | | | llvm-svn: 202811
* move getNameWithPrefix and getSymbol to TargetMachine.Rafael Espindola2014-02-191-4/+3
| | | | | | | | | | TargetLoweringBase is implemented in CodeGen, so before this patch we had a dependency fom Target to CodeGen. This would show up as a link failure of llvm-stress when building with -DBUILD_SHARED_LIBS=ON. This fixes pr18900. llvm-svn: 201711
* Add back r201608, r201622, r201624 and r201625Rafael Espindola2014-02-191-17/+16
| | | | | | | | | | | | | | r201608 made llvm corretly handle private globals with MachO. r201622 fixed a bug in it and r201624 and r201625 were changes for using private linkage, assuming that llvm would do the right thing. They all got reverted because r201608 introduced a crash in LTO. This patch includes a fix for that. The issue was that TargetLoweringObjectFile now has to be initialized before we can mangle names of private globals. This is trivially true during the normal codegen pipeline (the asm printer does it), but LTO has to do it manually. llvm-svn: 201700
* Revert r201622 and r201608.Daniel Jasper2014-02-191-16/+17
| | | | | | | This causes the LLVMgold plugin to segfault. More information on the replies to r201608. llvm-svn: 201669
* Fix PR18743.Rafael Espindola2014-02-181-17/+16
| | | | | | | | | | | | | | | | | | | | | | | | The IR @foo = private constant i32 42 is valid, but before this patch we would produce an invalid MachO from it. It was invalid because it would use an L label in a section where the liker needs the labels in order to atomize it. One way of fixing it would be to just reject this IR in the backend, but that would not be very front end friendly. What this patch does is use an 'l' prefix in sections that we know the linker requires symbols for atomizing them. This allows frontends to just use private and not worry about which sections they go to or how the linker handles them. One small issue with this strategy is that now a symbol name depends on the section, which is not available before codegen. This is not a problem in practice. The reason is that it only happens with private linkage, which will be ignored by the non codegen users (llvm-nm and llvm-ar). llvm-svn: 201608
OpenPOWER on IntegriCloud