aboutsummaryrefslogtreecommitdiff
path: root/llvm/lib/Target/TargetLoweringObjectFile.cpp
AgeCommit message (Collapse)AuthorFilesLines
2016-02-22[X86] Create mergeable constant pool entries for AVXDavid Majnemer1-0/+1
We supported creating mergeable constant pool entries for smaller constants but not for 32-byte AVX constants. llvm-svn: 261584
2016-02-21[X86] Use the correct alignment for COMDAT constant pool entriesDavid Majnemer1-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
2015-11-18Stop producing .data.rel sections.Rafael Espindola1-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
2015-11-17Drop prelink support.Rafael Espindola1-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
2015-11-03CodeGen, Target: Move Mach-O-specific symbol name logic to Mach-O lowering.Peter Collingbourne1-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
2015-07-16Remove DataLayout from TargetLoweringObjectFile, redirect to ModuleMehdi Amini1-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
2015-06-16Clean up redundant copies of Triple objects. NFCDaniel Sanders1-1/+1
Summary: Reviewers: rengolin Reviewed By: rengolin Subscribers: llvm-commits, rengolin, jholewinski Differential Revision: http://reviews.llvm.org/D10382 llvm-svn: 239823
2015-06-16Recommit r239721: Replace string GNU Triples with llvm::Triple in ↵Daniel Sanders1-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
2015-06-15Revert r239721 - Replace string GNU Triples with llvm::Triple in ↵Daniel Sanders1-2/+2
InitMCObjectFileInfo. NFC. It appears to cause sparc-little-endian.s to assert on Windows and Darwin. llvm-svn: 239724
2015-06-15Replace string GNU Triples with llvm::Triple in InitMCObjectFileInfo. NFC.Daniel Sanders1-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
2015-05-30MC: Clean up MCExpr naming. NFC.Jim Grosbach1-4/+4
llvm-svn: 238634
2015-05-21Move alignment from MCSectionData to MCSection.Rafael Espindola1-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
2015-05-18MC: Clean up method names in MCContext.Jim Grosbach1-2/+2
The naming was a mish-mash of old and new style. Update to be consistent with the new. NFC. llvm-svn: 237594
2015-03-27Remove superfluous .str() and replace std::string concatenation with Twine.Yaron Keren1-1/+1
llvm-svn: 233392
2015-03-17COFF: Let globals with private linkage reside in their own sectionDavid Majnemer1-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
2015-03-17Revert "COFF: Let globals with private linkage reside in their own section"David Majnemer1-6/+0
This reverts commit r232539. This was committed accidently. llvm-svn: 232543
2015-03-17COFF: Let globals with private linkage reside in their own sectionDavid Majnemer1-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
2015-02-17Add r228939 back with a fix.Rafael Espindola1-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
2015-02-14Revert "On ELF, put PIC jump tables in a non executable section."Matthias Braun1-18/+0
This reverts commit r228939. The commit broke something in the output of exception handling tables on darwin x86-64. llvm-svn: 229203
2015-02-12On ELF, put PIC jump tables in a non executable section.Rafael Espindola1-0/+18
Fixes PR22558. llvm-svn: 228939
2015-02-12Put each jump table in an independent section if the function is too.Rafael Espindola1-0/+5
This allows the linker to GC both, fixing pr22557. llvm-svn: 228937
2015-01-29Remove MergeableConst.Rafael Espindola1-1/+2
Only the specific ones (MergeableConst4, MergeableConst8, MergeableConst16) are handled specially. llvm-svn: 227440
2015-01-26Move DataLayout back to the TargetMachine from TargetSubtargetInfoEric Christopher1-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
2015-01-09Recommit r224935 with a fix for the ObjC++/AArch64 bug that that revisionLang Hames1-6/+0
introduced. A test case for the bug was already committed in r225385. Patch by Rafael Espindola. llvm-svn: 225534
2015-01-06Revert r224935 "Refactor duplicated code. No intended functionality change."Lang Hames1-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
2014-12-29Refactor duplicated code.Rafael Espindola1-6/+0
No intended functionality change. llvm-svn: 224935
2014-11-12Remove a bit of dead code.Rafael Espindola1-19/+0
Every "real" object file implements this an ptx doesn't use it. llvm-svn: 221746
2014-08-04Remove the TargetMachine forwards for TargetSubtargetInfo basedEric Christopher1-2/+4
information and update all callers. No functional change. llvm-svn: 214781
2014-07-14CodeGen: Stick constant pool entries in COMDAT sections for WinCOFFDavid Majnemer1-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
2014-05-17Target: Replace getSection().empty() with hasSection()David Majnemer1-1/+1
No functional change, just a small cleanup. llvm-svn: 209064
2014-04-25[C++] Use 'nullptr'. Target edition.Craig Topper1-4/+4
llvm-svn: 207197
2014-04-16Target: whitespaceSaleem Abdulrasool1-1/+1
llvm-svn: 206353
2014-03-04[cleanup] Re-sort all the includes with utils/sort_includes.py.Chandler Carruth1-1/+1
llvm-svn: 202811
2014-02-19move getNameWithPrefix and getSymbol to TargetMachine.Rafael Espindola1-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
2014-02-19Add back r201608, r201622, r201624 and r201625Rafael Espindola1-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
2014-02-19Revert r201622 and r201608.Daniel Jasper1-16/+17
This causes the LLVMgold plugin to segfault. More information on the replies to r201608. llvm-svn: 201669
2014-02-18Fix PR18743.Rafael Espindola1-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
2014-02-09Use a consistent argument order in TargetLoweringObjectFile.Rafael Espindola1-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
2014-02-08Pass the Mangler by reference.Rafael Espindola1-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
2014-01-28Revert r199871 and replace it with a simple check in the debug infoEric Christopher1-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
2014-01-23Add a variable to track whether or not we've used a unique section,Eric Christopher1-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
2014-01-07Move the llvm mangler to lib/IR.Rafael Espindola1-1/+1
This makes it available to tools that don't link with target (like llvm-ar). llvm-svn: 198708
2014-01-07Don't assert with private type info variables.Rafael Espindola1-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
2014-01-03Make the llvm mangler depend only on DataLayout.Rafael Espindola1-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
2013-12-05Remove the isImplicitlyPrivate argument of getNameWithPrefix.Rafael Espindola1-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
2013-12-02Move getSymbolWithGlobalValueBase to TargetLoweringObjectFile.Rafael Espindola1-0/+7
This allows it to be used in TargetLoweringObjectFileImpl.cpp. llvm-svn: 196117
2013-10-29Move getSymbol to TargetLoweringObjectFile.Rafael Espindola1-2/+12
This allows constructing a Mangler with just a TargetMachine. llvm-svn: 193630
2013-07-02[DebugInfo] Allow getDebugThreadLocalSymbol to return MCExprUlrich Weigand1-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
2013-06-28DebugInfo: PR14728: TLS supportDavid Blaikie1-0/+6
Based on GCC's output for TLS variables (OP_constNu, x@dtpoff, OP_lo_user), this implements debug info support for TLS in ELF. Verified that this output is correct/sufficient on Linux (using gold - if you're using binutils-ld, you'll need something with the fix for http://sourceware.org/bugzilla/show_bug.cgi?id=15685 in it). Support on non-ELF is sort of "arbitrary" at the moment - if Apple folks want to discuss (or just go ahead & implement) how this should work in MachO, etc, I'm open. llvm-svn: 185203
2013-01-02Move all of the header files which are involved in modelling the LLVM IRChandler Carruth1-5/+5
into their new header subdirectory: include/llvm/IR. This matches the directory structure of lib, and begins to correct a long standing point of file layout clutter in LLVM. There are still more header files to move here, but I wanted to handle them in separate commits to make tracking what files make sense at each layer easier. The only really questionable files here are the target intrinsic tablegen files. But that's a battle I'd rather not fight today. I've updated both CMake and Makefile build systems (I think, and my tests think, but I may have missed something). I've also re-sorted the includes throughout the project. I'll be committing updates to Clang, DragonEgg, and Polly momentarily. llvm-svn: 171366
generated by cgit v1.1 at 2025-10-13 21:15:01 +0000