summaryrefslogtreecommitdiffstats
path: root/llvm/lib/CodeGen/TargetLoweringObjectFileImpl.cpp
Commit message (Collapse)AuthorAgeFilesLines
* IR: Replace the "Linker Options" module flag with "llvm.linker.options" ↵Peter Collingbourne2017-06-121-33/+16
| | | | | | | | | | named metadata. The new metadata is easier to manipulate than module flags. Differential Revision: https://reviews.llvm.org/D31349 llvm-svn: 305227
* Move Object format code to lib/BinaryFormat.Zachary Turner2017-06-071-4/+4
| | | | | | | | | | | | 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
* Sort the remaining #include lines in include/... and lib/....Chandler Carruth2017-06-061-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | 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
* CodeGen: add support for emitting ObjC image infoSaleem Abdulrasool2017-06-051-23/+70
| | | | | | | | | This ensures that we can emit the ObjC Image Info structure on COFF and ELF as well. The frontend already would attempt to emit this information but would get dropped when generating assembly or an object file. llvm-svn: 304736
* Add support for #pragma clang sectionJaved Absar2017-06-051-0/+19
| | | | | | | | | | | | | | | 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
* Ignore !associated metadata with null argument.Evgeniy Stepanov2017-05-081-1/+5
| | | | | | | Fixes PR32577 (comment 10). Such metadata may legitimately appear in LTO. llvm-svn: 302485
* [ProfileData] Unify getInstrProf*SectionName helpersVedant Kumar2017-04-151-1/+2
| | | | | | | | | | | | | | | | | | | | | | This is a version of D32090 that unifies all of the `getInstrProf*SectionName` helper functions. (Note: the build failures which D32090 would have addressed were fixed with r300352.) We should unify these helper functions because they are hard to use in their current form. E.g we recently introduced more helpers to fix section naming for COFF files. This scheme doesn't totally succeed at hiding low-level details about section naming, so we should switch to an API that is easier to maintain. This is not an NFC commit because it fixes llvm-cov's testing support for COFF files (this falls out of the API change naturally). This is an area where we lack tests -- I will see about adding one as a follow up. Testing: check-clang, check-profile, check-llvm. Differential Revision: https://reviews.llvm.org/D32097 llvm-svn: 300381
* [Profile] Make host tool aware of object format when quering prof section names Xinliang David Li2017-04-141-4/+2
| | | | | | Differential Revision: https://reviews.llvm.org/D32073 llvm-svn: 300352
* [Profile] PE binary coverage bug fixXinliang David Li2017-04-131-1/+3
| | | | | | | | PR/32584 Differential Revision: https://reviews.llvm.org/D32023 llvm-svn: 300277
* Move llvm::emitLinkerFlagsForGlobalCOFF() to Mangler.Peter Collingbourne2017-03-311-31/+0
| | | | llvm-svn: 299183
* Add !associated metadata.Evgeniy Stepanov2017-03-171-13/+50
| | | | | | | | | | | | | | | | This is an ELF-specific thing that adds SHF_LINK_ORDER to the global's section pointing to the metadata argument's section. The effect of that is a reverse dependency between sections for the linker GC. !associated does not change the behavior of global-dce. The global may also need to be added to llvm.compiler.used. Since SHF_LINK_ORDER is per-section, !associated effectively enables fdata-sections for the affected globals, the same as comdats do. Differential Revision: https://reviews.llvm.org/D29104 llvm-svn: 298157
* [CodeGen] Fix some Clang-tidy modernize and Include What You Use warnings; ↵Eugene Zelenko2017-02-271-12/+24
| | | | | | other minor fixes (NFC). llvm-svn: 296404
* [WebAssembly] Basic support for Wasm object file encoding.Dan Gohman2017-02-241-3/+58
| | | | | | | | | With the "wasm32-unknown-unknown-wasm" triple, this allows writing out simple wasm object files, and is another step in a larger series toward migrating from ELF to general wasm object support. Note that this code and the binary format itself is still experimental. llvm-svn: 296190
* [WebAssembly] Add skeleton MC support for the Wasm container formatDan Gohman2017-02-221-0/+52
| | | | | | | | | This just adds the basic skeleton for supporting a new object file format. All of the actual encoding will be implemented in followup patches. Differential Revision: https://reviews.llvm.org/D26722 llvm-svn: 295803
* [lto] add getLinkerOpts()Bob Haarman2017-02-021-29/+32
| | | | | | | | | | | | Summary: Some compilers, including MSVC and Clang, allow linker options to be specified in source files. In the legacy LTO API, there is a getLinkerOpts() method that returns linker options for the bitcode module being processed. This change adds that method to the new API, so that the COFF linker can get the right linker options when using the new LTO API. Reviewers: pcc, ruiu, mehdi_amini, tejohnson Reviewed By: pcc Differential Revision: https://reviews.llvm.org/D29207 llvm-svn: 293950
* Revert "[COFF] Use 32-bit jump table entries in .rdata for Win64"Reid Kleckner2016-12-291-7/+0
| | | | | | | | This reverts commit r290694. It broke sanitizer tests on Win64. I'll probably bring this back, but the jump tables will just live in .text like they do for MSVC. llvm-svn: 290714
* [COFF] Use 32-bit jump table entries in .rdata for Win64Reid Kleckner2016-12-291-0/+7
| | | | | | | | | | | | | | | | | | | | | | | | | Summary: We were already using 32-bit jump table entries, but this was a consequence of the default PIC model on Win64, and not an intentional design decision. This patch ensures that we always use 32-bit label difference jump table entries on Win64 regardless of the PIC model. This is a good idea because it saves executable size and object file size. Moving the jump tables to .rdata cleans up the disassembled object code and reduces the available ROP targets, but it requires adding one more RIP-relative lea to the code. COFF doesn't have relocations to express the difference between two arbitrary symbols, so we can't use the jump table label in the label difference like we do elsewhere. Fixes PR31488 Reviewers: majnemer, compnerd Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D28141 llvm-svn: 290694
* [ARM] Implement execute-only support in CodeGenPrakhar Bahuguna2016-12-151-0/+6
| | | | | | | | | | | | | | | | | | | | This implements execute-only support for ARM code generation, which prevents the compiler from generating data accesses to code sections. The following changes are involved: * Add the CodeGen option "-arm-execute-only" to the ARM code generator. * Add the clang flag "-mexecute-only" as well as the GCC-compatible alias "-mpure-code" to enable this option. * When enabled, literal pools are replaced with MOVW/MOVT instructions, with VMOV used in addition for floating-point literals. As the MOVT instruction is required, execute-only support is only available in Thumb mode for targets supporting ARMv8-M baseline or Thumb2. * Jump tables are placed in data sections when in execute-only mode. * The execute-only text section is assigned section ID 0, and is marked as unreadable with the SHF_ARM_PURECODE flag with symbol 'y'. This also overrides selection of ELF sections for globals. llvm-svn: 289784
* CodeGen: simplify TargetMachine::getSymbol interface. NFC.Tim Northover2016-11-221-11/+10
| | | | | | | | | 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-45/+48
| | | | | | | | | | | | | | | | 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
* Use profile info to set function section prefix to group hot/cold functions.Dehao Chen2016-10-181-2/+6
| | | | | | | | | | | | | | | | Summary: The original implementation is in r261607, which was reverted in r269726 to accomendate the ProfileSummaryInfo analysis pass. The new implementation: 1. add a new metadata for function section prefix 2. query against ProfileSummaryInfo in CGP to set the correct section prefix for each function 3. output the section prefix set by CGP Reviewers: davidxl, eraman Subscribers: vsk, llvm-commits Differential Revision: https://reviews.llvm.org/D24989 llvm-svn: 284533
* Revert "In preparation for removing getNameWithPrefix off ofEric Christopher2016-10-141-8/+1
| | | | | | | | | TargetMachine," as it's causing sanitizer/memory issues until I can track down this set. This reverts commit r284203 llvm-svn: 284252
* In preparation for removing getNameWithPrefix off of TargetMachine,Eric Christopher2016-10-141-1/+8
| | | | | | | sink the current behavior into the callers and sink TargetMachine::getNameWithPrefix into TargetMachine::getSymbol. llvm-svn: 284203
* Revert "Remove extra argument used once onEric Christopher2016-09-201-8/+1
| | | | | | | | | | | | TargetMachine::getNameWithPrefix and inline the result into the singular caller." and "Remove more guts of TargetMachine::getNameWithPrefix and migrate one check to the TLOF mach-o version." temporarily until I can get the whole call migrated out of the TargetMachine as we could hit places where TLOF isn't valid. This reverts commits r281981 and r281983. llvm-svn: 282028
* Mark ELF sections whose name start with .note as notePetr Hosek2016-09-201-0/+5
| | | | | | | | | | | Previously, such section would be marked as SHT_PROGBITS which makes it impossible to use an initialized C variable declaration to emit an (allocated) ELF note. The new behavior is also consistent with ELF assembly parser. Differential Revision: https://reviews.llvm.org/D24692 llvm-svn: 282010
* Remove more guts of TargetMachine::getNameWithPrefix and migrate one check ↵Eric Christopher2016-09-201-0/+7
| | | | | | | | to the TLOF mach-o version. NFC intended. llvm-svn: 281983
* Remove extra argument used once on TargetMachine::getNameWithPrefix and ↵Eric Christopher2016-09-201-1/+1
| | | | | | inline the result into the singular caller. llvm-svn: 281981
* Move the Mangler from the AsmPrinter down to TLOF and clean up theEric Christopher2016-09-161-60/+49
| | | | | | TLOF API accordingly. llvm-svn: 281708
* Use the correct ctor/dtor section for dynamic-no-pic.Rafael Espindola2016-08-291-1/+1
| | | | llvm-svn: 279967
* Move code only used by codegen out of MC. NFC.Rafael Espindola2016-08-291-5/+55
| | | | | | MC itself never needs to know about these sections. llvm-svn: 279965
* Add support for allowing us to create uniquely identified "COMDAT" or "ELFEric Christopher2016-07-011-4/+2
| | | | | | | | | | | | | Group" sections while lowering. In particular, for ELF sections this is useful for creating function-specific groups that get merged into the same named section. Also use const Twine& instead of StringRef for the getELF functions while we're here. Differential Revision: http://reviews.llvm.org/D21743 llvm-svn: 274336
* [ARM] Fix Thumb text sections' flags under COFF/WindowsRenato Golin2016-06-271-5/+7
| | | | | | | | | | | | | | | | The main issue here is that the "thumb" flag wasn't set for some of these sections, making MSVC's link.exe fails to correctly relocate code against the symbols inside these sections. link.exe could fail for instance with the "fixup is not aligned for target 'XX'" error. If linking doesn't fail, the relocation process goes wrong in the end and invalid code is generated by the linker. This patch adds Thumb/ARM information so that the right flags are set on COFF/Windows. Patch by Adrien Guinet. llvm-svn: 273880
* 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
* Simplify handling of hidden stub.Rafael Espindola2016-05-171-3/+1
| | | | | | | | | Since r207518 they are printed exactly like non-hidden stubs on x86 and since r207517 on ARM. This means we can use a single set for all stubs in those platforms. llvm-svn: 269776
* Remove .hot and .unlikely prefixes from function section names.Easwaran Raman2016-05-161-16/+2
| | | | | | This code currently relies on static methods in ProfileSummary to determine whether a function is hot or unlikley. I am refactoring the ProfileSummary code and these methods will be removed. As discussed offline, the right way to re-introduce this is to add a pass to annotate functions with unlikely/hot hints and use the hints to determine the prefix here. llvm-svn: 269726
* [MC] Create unique .pdata sections for every .text sectionReid Kleckner2016-05-021-10/+13
| | | | | | | | | | | | | | | | | | | | | | | | Summary: This adds a unique ID to the COFF section uniquing map, similar to the one we have for ELF. The unique id is not currently exposed via the assembler because we don't have a use case for it yet. Users generally create .pdata with the .seh_* family of directives, and the assembler internally needs to produce .pdata and .xdata sections corresponding to the code section. The association between .text sections and the assembler-created .xdata and .pdata sections is maintained as an ID field of MCSectionCOFF. The CFI-related sections are created with the given unique ID, so if more code is added to the same text section, we can find and reuse the CFI sections that were already created. Reviewers: majnemer, rafael Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D19376 llvm-svn: 268331
* CodeGen: convert to range based loopsSaleem Abdulrasool2016-04-301-36/+20
| | | | | | | Convert to using some range based loops, avoid unnecessary variables for unchecked casts. NFC. llvm-svn: 268165
* CodeGen: Use PLT relocations for relative references to unnamed_addr functions.Peter Collingbourne2016-04-221-0/+21
| | | | | | | | | | | | | 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
* Add prefix based function layout when profile is available.Dehao Chen2016-02-231-0/+16
| | | | | | | | | | | | Summary: If a function is hot, put it in text.hot section. Reviewers: davidxl Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D17532 llvm-svn: 261607
* Revert "Add prefix based function layout when profile is available."Duncan P. N. Exon Smith2016-02-231-16/+0
| | | | | | | | This reverts commit r261582, since this bot has been broken for four hours: http://lab.llvm.org:8080/green/job/clang-stage1-cmake-RA-incremental_check/19399/ llvm-svn: 261604
* [X86] Create mergeable constant pool entries for AVXDavid Majnemer2016-02-221-2/+6
| | | | | | | We supported creating mergeable constant pool entries for smaller constants but not for 32-byte AVX constants. llvm-svn: 261584
* Add prefix based function layout when profile is available.Dehao Chen2016-02-221-0/+16
| | | | | | | | | | | | Summary: If a function is hot, put it in text.hot section. Reviewers: davidxl Subscribers: eraman, mcrosier, llvm-commits Differential Revision: http://reviews.llvm.org/D17460 llvm-svn: 261582
* [X86] Use the correct alignment for COMDAT constant pool entriesDavid Majnemer2016-02-211-2/+4
| | | | | | | | | | | | | | | | | | | 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 creating covmap as note section on ELFXinliang David Li2016-02-181-3/+0
| | | | | | | | | | | | covmap needs to created as non allocatable, but not with SHT_NOTE. The latter was needed to workaround a problem of BFD linker with gc, which is no longer needed. (A more proper longer term fix requires changing FE driver to force referencing the section using linker script). Differential Revision: http://reviews.llvm.org/D17309 llvm-svn: 261228
* [Objective-C] Support a new special module flag.Manman Ren2016-01-291-0/+1
| | | | | | | | "Objective-C Class Properties" will be put into the objc_imageinfo struct. rdar://23891898 llvm-svn: 259270
* [PGO] [Coverage] put covmap into note section with no 'alloc flag' (Linux)Xinliang David Li2016-01-141-0/+8
| | | | | | | | | | | Coverage mapping data is not referenced by runtime, and they won't be dumped into profile data. There is no need to allocate memory for covmap sections. A good side effect of this change is that the coverage map data won't be mistakenly garbage collected by the linker (for Gold linker only, BFD linker has an issue where the a bug is filed). Tested with clang build with instrumentation and -fcoverage-mapping and linker GC. The size of covmap section is ~17.6M so the text segment size will be reduced by this amount with this change. llvm-svn: 257781
* Stop producing .data.rel sections.Rafael Espindola2015-11-181-5/+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-5/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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/+28
| | | | | | | | | | | | | | | | | 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
* 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
OpenPOWER on IntegriCloud