summaryrefslogtreecommitdiffstats
path: root/llvm/lib/Target/X86/X86TargetObjectFile.cpp
Commit message (Collapse)AuthorAgeFilesLines
* Revert "Honor -fuse-init-array when os is not specified on x86"Mitch Phillips2019-12-171-1/+22
| | | | | | | This reverts commit aa5ee8f244441a8ea103a7e0ed8b6f3e74454516. This change broke the sanitizer buildbots. See comments at the patchset (https://reviews.llvm.org/D71360) for more information.
* Honor -fuse-init-array when os is not specified on x86Kamlesh Kumar2019-12-161-22/+1
| | | | | | | | | | | | | | | | | | | | | Currently -fuse-init-array option is not effective when target triple does not specify os, on x86,x86_64. i.e. // -fuse-init-array is not honored. $ clang -target i386 -fuse-init-array test.c -S // -fuse-init-array is honored. $ clang -target i386-linux -fuse-init-array test.c -S This patch fixes first case. And does cleanup. Reviewers: rnk, craig.topper, fhahn, echristo Reviewed By: rnk Differential Revision: https://reviews.llvm.org/D71360
* [MachO][TLOF] Use hasLocalLinkage to determine if indirect symbol is localFrancis Visoiu Mistrih2019-08-221-2/+2
| | | | | | | | | | | | | | | | | | | | | Local symbols in the indirect symbol table contain the value `INDIRECT_SYMBOL_LOCAL` and the corresponding __pointers entry must contain the address of the target. In r349060, I added support for local symbols in the indirect symbol table, which was checking if the symbol `isDefined` && `!isExternal` to determine if the symbol is local or not. It turns out that `isDefined` will return false if the user of the symbol comes before its definition, and we'll again generate .long 0 which will be the symbol at the adress 0x0. Instead of doing that, use GlobalValue::hasLocalLinkage() to check if the symbol is local. Differential Revision: https://reviews.llvm.org/D66563 llvm-svn: 369671
* 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
* [MS][ARM64] Hoist __ImageBase handling into TargetLoweringObjectFileCOFFReid Kleckner2018-06-121-97/+0
| | | | | | | | | | | | All COFF targets should use @IMGREL32 relocations for symbol differences against __ImageBase. Do the same for getSectionForConstant, so that immediates lowered to globals get merged across TUs. Patch by Chris January Differential Revision: https://reviews.llvm.org/D47783 llvm-svn: 334523
* Fix a bunch more layering of CodeGen headers that are in TargetDavid Blaikie2017-11-171-1/+1
| | | | | | | | All these headers already depend on CodeGen headers so moving them into CodeGen fixes the layering (since CodeGen depends on Target, not the other way around). llvm-svn: 318490
* [Solaris] emit .init_array instead of .ctors on Solaris (Sparc/x86)Davide Italiano2017-06-211-0/+6
| | | | | | | | Patch by Fedor Sergeev. Differential Revision: https://reviews.llvm.org/D33868 llvm-svn: 305948
* Move Object format code to lib/BinaryFormat.Zachary Turner2017-06-071-2/+2
| | | | | | | | | | | | 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
* CodeGen: simplify TargetMachine::getSymbol interface. NFC.Tim Northover2016-11-221-3/+3
| | | | | | | | | 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
* [Triple] Add triple for FuchsiaPetr Hosek2016-10-061-0/+7
| | | | | | | | Fuchsia is a new operating system. Differential Revision: https://reviews.llvm.org/D25116 llvm-svn: 283419
* [CodeGen] Add support for emitting .init_array instead of .ctors on FreeBSD.Davide Italiano2016-09-261-0/+7
| | | | | PR: 30494 llvm-svn: 282451
* Move the Mangler from the AsmPrinter down to TLOF and clean up theEric Christopher2016-09-161-10/+10
| | | | | | TLOF API accordingly. llvm-svn: 281708
* CodeGen: Use PLT relocations for relative references to unnamed_addr functions.Peter Collingbourne2016-04-221-34/+11
| | | | | | | | | | | | | The relative vtable ABI (PR26723) needs PLT relocations to refer to virtual functions defined in other DSOs. The unnamed_addr attribute means that the function's address is not significant, so we're allowed to substitute it with the address of a PLT entry. Also includes a bonus feature: addends for COFF image-relative references. Differential Revision: http://reviews.llvm.org/D17938 llvm-svn: 267211
* [X86] Create mergeable constant pool entries for AVXDavid Majnemer2016-02-221-0/+5
| | | | | | | 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-6/+19
| | | | | | | | | | | | | | | | | | | 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
* Sink COFF.h MC include into .cpp filesReid Kleckner2015-09-031-0/+1
| | | | | | | | This prevents MC clients from getting COFF.h, which conflicts with winnt.h macros. Also a minor IWYU cleanup. Now the only public headers including COFF.h are in Object, and they actually need it. llvm-svn: 246784
* Remove DataLayout from TargetLoweringObjectFile, redirect to ModuleMehdi Amini2015-07-161-4/+3
| | | | | | | | | | | | | | | | 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
* Revert "Revert r240762 "[X86] Cleanup ↵David Majnemer2015-06-261-36/+28
| | | | | | | | | | | X86WindowsTargetObjectFile::getSectionForConstant"" This reverts commit r240793 while fixing how we handle array constant pool entries. This fixes PR23966. llvm-svn: 240811
* Revert r240762 "[X86] Cleanup X86WindowsTargetObjectFile::getSectionForConstant"Hans Wennborg2015-06-261-25/+37
| | | | | | It seems to have caused PR23966: "UNREACHABLE executed at ..\lib\Target\X86\X86TargetObjectFile.cpp:148" llvm-svn: 240793
* [X86] Cleanup X86WindowsTargetObjectFile::getSectionForConstantDavid Majnemer2015-06-261-37/+25
| | | | | | No functionality changed, just keeping things clean. llvm-svn: 240762
* MC: Clean up MCExpr naming. NFC.Jim Grosbach2015-05-301-8/+8
| | | | llvm-svn: 238634
* Move alignment from MCSectionData to MCSection.Rafael Espindola2015-05-211-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | 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
* Make NaCl's use of .init_array for static constructors match LinuxDerek Schuff2015-03-111-1/+2
| | | | | | | | | | | | Summary: The generic ELF TargetObjectFile defaults to .ctors, but Linux's defaults to .init_array by calling InitializeELF with the value of UseInitArray from TargetMachine. Make NaCl's behavior match. Reviewers: jvoung Differential Revision: http://reviews.llvm.org/D8240 llvm-svn: 231934
* [AsmPrinter][TLOF] 32-bit MachO support for replacing GOT equivalentsBruno Cardoso Lopes2015-03-061-7/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | Add MachO 32-bit (i.e. arm and x86) support for replacing global GOT equivalent symbol accesses. Unlike 64-bit targets, there's no GOTPCREL relocation, and access through a non_lazy_symbol_pointers section is used instead. -- before _extgotequiv: .long _extfoo _delta: .long _extgotequiv-_delta -- after _delta: .long L_extfoo$non_lazy_ptr-_delta .section __IMPORT,__pointers,non_lazy_symbol_pointers L_extfoo$non_lazy_ptr: .indirect_symbol _extfoo .long 0 llvm-svn: 231475
* [AsmPrinter][TLOF] ARM64 MachO support for replacing GOT equivalentsBruno Cardoso Lopes2015-03-061-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Follow up r230264 and add ARM64 support for replacing global GOT equivalent symbol accesses by references to the GOT entry for the final symbol instead, example: -- before .globl _foo _foo: .long 42 .globl _gotequivalent _gotequivalent: .quad _foo .globl _delta _delta: .long _gotequivalent-_delta -- after .globl _foo _foo: .long 42 .globl _delta Ltmp3: .long _foo@GOT-Ltmp3 llvm-svn: 231474
* X86: Form IMGREL relocations for LLVM FunctionsDavid Majnemer2015-03-061-9/+7
| | | | | | | | We supported forming IMGREL relocations from ConstantExprs involving __ImageBase if the minuend was a GlobalVariable. Extend this functionality to all GlobalObjects. llvm-svn: 231456
* [X86][ELF] Correct relocation for DWARF TLS referencesPaul Robinson2015-03-031-6/+5
| | | | | | | | | Previously we had only Linux using DTPOFF for these; all X86 ELF targets should. Fixes a side issue mentioned in PR21077. Differential Revision: http://reviews.llvm.org/D8011 llvm-svn: 231130
* Revert r230979, should apply to all X86 ELF.Paul Robinson2015-03-021-5/+0
| | | | llvm-svn: 230985
* [PS4] Correct relocation for DWARF TLS references.Paul Robinson2015-03-021-0/+5
| | | | llvm-svn: 230979
* [AsmPrinter] Access pointers to globals via pcrel GOT entriesBruno Cardoso Lopes2015-02-231-0/+16
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Front-ends could use global unnamed_addr to hold pointers to other symbols, like @gotequivalent below: @foo = global i32 42 @gotequivalent = private unnamed_addr constant i32* @foo @delta = global i32 trunc (i64 sub (i64 ptrtoint (i32** @gotequivalent to i64), i64 ptrtoint (i32* @delta to i64)) to i32) The global @delta holds a data "PC"-relative offset to @gotequivalent, an unnamed pointer to @foo. The darwin/x86-64 assembly output for this follows: .globl _foo _foo: .long 42 .globl _gotequivalent _gotequivalent: .quad _foo .globl _delta _delta: .long _gotequivalent-_delta Since unnamed_addr indicates that the address is not significant, only the content, we can optimize the case above by replacing pc-relative accesses to "GOT equivalent" globals, by a PC relative access to the GOT entry of the final symbol instead. Therefore, "delta" can contain a pc relative relocation to foo's GOT entry and we avoid the emission of "gotequivalent", yielding the assembly code below: .globl _foo _foo: .long 42 .globl _delta _delta: .long _foo@GOTPCREL+4 There are a couple of advantages of doing this: (1) Front-ends that need to emit a great deal of data to store pointers to external symbols could save space by not emitting such "got equivalent" globals and (2) IR constructs combined with this opt opens a way to represent GOT pcrel relocations by using the LLVM IR, which is something we previously had no way to express. Differential Revision: http://reviews.llvm.org/D6922 rdar://problem/18534217 llvm-svn: 230264
* X86: Simplify X86WindowsTargetObjectFile::getSectionForConstantDavid Majnemer2014-07-151-9/+3
| | | | | | | | | There exists a helper function to abstract away the various differences between ConstantVector, ConstantDataVector, ConstantAggregateZero, etc. Use it to simplify X86WindowsTargetObjectFile::getSectionForConstant. llvm-svn: 213104
* CodeGen: Handle ConstantVector and undef in WinCOFF constant poolsDavid Majnemer2014-07-151-13/+21
| | | | | | | | | | | | The constant pool entry code for WinCOFF assumed that vector constants would be formed using ConstantDataVector, it did not expect to see a ConstantVector. Furthermore, it did not expect undef as one of the elements of the vector. ConstantVectors should be handled like ConstantDataVectors, treat Undef as zero. llvm-svn: 213038
* CodeGen: Stick constant pool entries in COMDAT sections for WinCOFFDavid Majnemer2014-07-141-0/+61
| | | | | | | | | | | | | | | | 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
* Restore condition incorrectly changed in r96289 to the older state.Joerg Sonnenberger2014-04-301-1/+1
| | | | llvm-svn: 207716
* [C++] Use 'nullptr'. Target edition.Craig Topper2014-04-251-6/+6
| | | | llvm-svn: 207197
* move getNameWithPrefix and getSymbol to TargetMachine.Rafael Espindola2014-02-191-3/+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-12/+14
| | | | | | | | | | | | | | 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-14/+12
| | | | | | | This causes the LLVMgold plugin to segfault. More information on the replies to r201608. llvm-svn: 201669
* Fix PR18743.Rafael Espindola2014-02-181-12/+14
| | | | | | | | | | | | | | | | | | | | | | | | 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
* WinCOFF: Transform IR expressions featuring __ImageBase into image relative ↵David Majnemer2014-01-151-0/+52
| | | | | | | | | | | | | relocations MSVC on x64 requires that we create image relative symbol references to refer to RTTI data. Seeing as how there is no way to explicitly make reference to a given relocation type in LLVM IR, pattern match expressions of the form &foo - &__ImageBase. Differential Revision: http://llvm-reviews.chandlerc.com/D2523 llvm-svn: 199312
* Re-sort #include lines again, prior to moving headers around.Chandler Carruth2014-01-131-1/+1
| | | | llvm-svn: 199080
* 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
* Move getSymbol to TargetLoweringObjectFile.Rafael Espindola2013-10-291-2/+2
| | | | | | 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
* PR16493: DebugInfo with TLS on PPC crashing due to invalid relocationDavid Blaikie2013-07-011-0/+6
| | | | | | | | Restrict the current TLS support to X86 ELF for now. Test that we don't produce it on PPC & we can flesh that test case out with the right thing once someone implements it. llvm-svn: 185389
* Remove heavy and unused #inclues from X86TargetObjectFile.cpp.Jakub Staszak2013-01-101-5/+1
| | | | llvm-svn: 172151
* Use the new script to sort the includes of every file under lib.Chandler Carruth2012-12-031-1/+1
| | | | | | | | | | | | | | | | | Sooooo many of these had incorrect or strange main module includes. I have manually inspected all of these, and fixed the main module include to be the nearest plausible thing I could find. If you own or care about any of these source files, I encourage you to take some time and check that these edits were sensible. I can't have broken anything (I strictly added headers, and reordered them, never removed), but they may not be the headers you'd really like to identify as containing the API being implemented. Many forward declarations and missing includes were added to a header files to allow them to parse cleanly when included first. The main module rule does in fact have its merits. =] llvm-svn: 169131
* Use TARGET2 relocation for TType references on ARM.Anton Korobeynikov2012-11-141-4/+4
| | | | | | | | Do some cleanup of the code while here. Inspired by patch by Logan Chien! llvm-svn: 167904
OpenPOWER on IntegriCloud