summaryrefslogtreecommitdiffstats
path: root/llvm/lib/Target/TargetLoweringObjectFile.cpp
Commit message (Collapse)AuthorAgeFilesLines
* 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
* Use a consistent argument order in TargetLoweringObjectFile.Rafael Espindola2014-02-091-9/+8
| | | | | | | | | These methods normally call each other and it is really annoying if the arguments are in different order. The more common rule was that the arguments specific to call are first (GV, Encoding, Suffix) and the auxiliary objects (Mang, TM) come after. This patch changes the exceptions. llvm-svn: 201044
* Pass the Mangler by reference.Rafael Espindola2014-02-081-6/+6
| | | | | | | It is never null and it is not used in casts, so there is no reason to use a pointer. This matches how we pass TM. llvm-svn: 201025
* Revert r199871 and replace it with a simple check in the debug infoEric Christopher2014-01-281-4/+6
| | | | | | | | | code to see if we're emitting a function into a non-default text section. This is still a less-than-ideal solution, but more contained than r199871 to determine whether or not we're emitting code into an array of comdat sections. llvm-svn: 200269
* Add a variable to track whether or not we've used a unique section,Eric Christopher2014-01-231-6/+4
| | | | | | | | | | | | e.g. linkonce, to TargetMachine and set it when we've done so for ELF targets currently. This involved making TargetMachine non-const in a TLOF use and propagating that change around - I'm open to other ideas. This will be used in a future commit to handle emitting debug information with ranges. llvm-svn: 199871
* Move the llvm mangler to lib/IR.Rafael Espindola2014-01-071-1/+1
| | | | | | This makes it available to tools that don't link with target (like llvm-ar). llvm-svn: 198708
* Don't assert with private type info variables.Rafael Espindola2014-01-071-3/+0
| | | | | | | With the gnu objc runtime private strings are used. Since we only need to produce a unique label, the fix is to just drop the asserts. llvm-svn: 198701
* Make the llvm mangler depend only on DataLayout.Rafael Espindola2014-01-031-2/+2
| | | | | | | | | | | | | | Before this patch any program that wanted to know the final symbol name of a GlobalValue had to link with Target. This patch implements a compromise solution where the mangler uses DataLayout. This way, any tool that already links with Target (llc, clang) gets the exact behavior as before and new IR files can be mangled without linking with Target. With this patch the mangler is constructed with just a DataLayout and DataLayout is extended to include the information the Mangler needs. llvm-svn: 198438
* Remove the isImplicitlyPrivate argument of getNameWithPrefix.Rafael Espindola2013-12-051-2/+10
| | | | | | | | | | | | getSymbolWithGlobalValueBase use is to create a name of a new symbol based on the name of an existing GV. Assert that and then remove the last call to pass true to isImplicitlyPrivate. This gives the mangler API a 1:1 mapping from GV to names, which is what we need to drop the mangler dependency on the target (and use an extended datalayout instead). llvm-svn: 196472
* Move getSymbolWithGlobalValueBase to TargetLoweringObjectFile.Rafael Espindola2013-12-021-0/+7
| | | | | | This allows it to be used in TargetLoweringObjectFileImpl.cpp. llvm-svn: 196117
* Move getSymbol to TargetLoweringObjectFile.Rafael Espindola2013-10-291-2/+12
| | | | | | This allows constructing a Mangler with just a TargetMachine. llvm-svn: 193630
* [DebugInfo] Allow getDebugThreadLocalSymbol to return MCExprUlrich Weigand2013-07-021-1/+1
| | | | | | | | | | | This allows getDebugThreadLocalSymbol to return a generic MCExpr instead of just a MCSymbolRefExpr. This is in preparation for supporting debug info for TLS variables on PowerPC, where we need to describe the variable location using a more complex expression than just MCSymbolRefExpr. llvm-svn: 185460
OpenPOWER on IntegriCloud