summaryrefslogtreecommitdiffstats
path: root/llvm/lib/Object/IRObjectFile.cpp
Commit message (Collapse)AuthorAgeFilesLines
...
* Replace string GNU Triples with llvm::Triple in InitMCObjectFileInfo. NFC.Daniel Sanders2015-06-151-6/+6
| | | | | | | | | | | | | | | | | | | | | 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
* Object: Prepend __imp_ when mangling a dllimport symbol in IRObjectFile.Peter Collingbourne2015-06-111-0/+3
| | | | | | | | | | | | | | | | | We cannot prepend __imp_ in the IR mangler because a function reference may be emitted unmangled in a constant initializer. The linker is expected to resolve such references to thunks. This is covered by the new test case. Strictly speaking we ought to emit two undefined symbols, one with __imp_ and one without, as we cannot know which symbol the final object file will refer to. However, this would require rather intrusive changes to IRObjectFile, and lld works fine without it for now. This reimplements r239437, which was reverted in r239502. Differential Revision: http://reviews.llvm.org/D10400 llvm-svn: 239560
* Remove object_error::success and use std::error_code() insteadRui Ueyama2015-06-091-2/+2
| | | | | | | | | | | | make_error_code(object_error) is slow because object::object_category() uses a ManagedStatic variable. But the real problem is that the function is called too frequently. This patch uses std::error_code() instead of object_error::success. In most cases, we return "success", so this patch reduces number of function calls to that function. http://reviews.llvm.org/D10333 llvm-svn: 239409
* Remove MCAssembler.h include from MCStreamer.h and fix users of MCStreamer.hPete Cooper2015-05-151-0/+1
| | | | llvm-svn: 237483
* Be lazy about loading metadata in IRObjectFile.Rafael Espindola2015-03-131-1/+3
| | | | | | | This speeds up llvm-ar building lib64/libclangSema.a with debug IR files from 8.658015807 seconds to just 0.351036519 seconds :-) llvm-svn: 232221
* Make DataLayout Non-Optional in the ModuleMehdi Amini2015-03-041-6/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: DataLayout keeps the string used for its creation. As a side effect it is no longer needed in the Module. This is "almost" NFC, the string is no longer canonicalized, you can't rely on two "equals" DataLayout having the same string returned by getStringRepresentation(). Get rid of DataLayoutPass: the DataLayout is in the Module The DataLayout is "per-module", let's enforce this by not duplicating it more than necessary. One more step toward non-optionality of the DataLayout in the module. Make DataLayout Non-Optional in the Module Module->getDataLayout() will never returns nullptr anymore. Reviewers: echristo Subscribers: resistor, llvm-commits, jholewinski Differential Revision: http://reviews.llvm.org/D7992 From: Mehdi Amini <mehdi.amini@apple.com> llvm-svn: 231270
* Add missing includes. make_unique proliferated everywhere.Benjamin Kramer2015-03-011-0/+1
| | | | llvm-svn: 230909
* Introduce Target::createNullTargetStreamer and use it from IRObjectFile.Peter Collingbourne2015-02-191-0/+1
| | | | | | | | | A null MCTargetStreamer allows IRObjectFile to ignore target-specific directives. Previously we were crashing. Differential Revision: http://reviews.llvm.org/D7711 llvm-svn: 229797
* [cleanup] Re-sort all the #include lines in LLVM usingChandler Carruth2015-01-141-3/+3
| | | | | | | | | | | utils/sort_includes.py. I clearly haven't done this in a while, so more changed than usual. This even uncovered a missing include from the InstrProf library that I've added. No functionality changed here, just mechanical cleanup of the include order. llvm-svn: 225974
* Silence more static analyzer warnings.Michael Ilseman2014-12-151-0/+2
| | | | | | | | Add in definedness checks for shift operators, null checks when pointers are assumed by the code to be non-null, and explicit unreachables. llvm-svn: 224255
* Rename createIRObjectFile to just create.Rafael Espindola2014-12-091-2/+2
| | | | | | | It is a static method of IRObjectFile, so having to use IRObjectFile::createIRObjectFile was redundant. llvm-svn: 223822
* Move method out of line to make buildbot happy.Rafael Espindola2014-12-091-0/+2
| | | | llvm-svn: 223781
* Don't lookup an object symbol name in the module.Rafael Espindola2014-12-091-5/+2
| | | | | | | | | | | Instead, walk the obj symbol list in parallel to find the GV. This shouldn't change anything on ELF where global symbols are not mangled, but it is a step toward supporting other object formats. Gold itself is ELF only, but bfd ld supports COFF and the logic in the gold plugin could be reused on lld. llvm-svn: 223780
* Don't ever call materializeAllPermanently during LTO.Rafael Espindola2014-10-241-11/+1
| | | | | | | | | | To do this, change the representation of lazy loaded functions. The previous representation cannot differentiate between a function whose body has been removed and one whose body hasn't been read from the .bc file. That means that in order to drop a function, the entire body had to be read. llvm-svn: 220580
* LTO: introduce object file-based on-disk module format.Peter Collingbourne2014-09-181-1/+41
| | | | | | | | | | | | | | | | | | This format is simply a regular object file with the bitcode stored in a section named ".llvmbc", plus any number of other (non-allocated) sections. One immediate use case for this is to accommodate compilation processes which expect the object file to contain metadata in non-allocated sections, such as the ".go_export" section used by some Go compilers [1], although I imagine that in the future we could consider compiling parts of the module (such as large non-inlinable functions) directly into the object file to improve LTO efficiency. [1] http://golang.org/doc/install/gccgo#Imports Differential Revision: http://reviews.llvm.org/D4371 llvm-svn: 218078
* unique_ptrify IRObjectFile::createIRObjectFileDavid Blaikie2014-09-031-2/+2
| | | | | | | | I took a guess at the changes to the gold plugin, because that doesn't seem to build by default for me. Not sure what dependencies I might be missing for that. llvm-svn: 217056
* Pass a && to getLazyBitcodeModule.Rafael Espindola2014-09-031-1/+1
| | | | | | | | This forces callers to use std::move when calling it. It is somewhat odd to have code with std::move that doesn't always move, but it is also odd to have code without std::move that sometimes moves. llvm-svn: 217049
* Pass a std::unique_ptr<MemoryBuffer>& to getLazyBitcodeModule.Rafael Espindola2014-08-261-2/+1
| | | | | | | By taking a reference we can do the ownership transfer in one place instead of expecting every caller to do it. llvm-svn: 216492
* Pass a MemoryBufferRef when we can avoid taking ownership.Rafael Espindola2014-08-261-4/+1
| | | | | | | | | | | | | The attached patch simplifies a few interfaces that don't need to take ownership of a buffer. For example, both parseAssembly and parseBitcodeFile will parse the entire buffer before returning. There is no need to take ownership. Using a MemoryBufferRef makes it obvious in the type signature that there is no ownership transfer. llvm-svn: 216488
* Explicitly pass ownership of the MemoryBuffer to AddNewSourceBuffer using ↵David Blaikie2014-08-211-1/+1
| | | | | | std::unique_ptr llvm-svn: 216223
* Don't own the buffer in object::Binary.Rafael Espindola2014-08-191-10/+14
| | | | | | | | | | | | | | | | | | | | | | | | | Owning the buffer is somewhat inflexible. Some Binaries have sub Binaries (like Archive) and we had to create dummy buffers just to handle that. It is also a bad fit for IRObjectFile where the Module wants to own the buffer too. Keeping this ownership would make supporting IR inside native objects particularly painful. This patch focuses in lib/Object. If something elsewhere used to own an Binary, now it also owns a MemoryBuffer. This patch introduces a few new types. * MemoryBufferRef. This is just a pair of StringRefs for the data and name. This is to MemoryBuffer as StringRef is to std::string. * OwningBinary. A combination of Binary and a MemoryBuffer. This is needed for convenience functions that take a filename and return both the buffer and the Binary using that buffer. The C api now uses OwningBinary to avoid any change in semantics. I will start a new thread to see if we want to change it and how. llvm-svn: 216002
* Make RecordStreamer.h private.Rafael Espindola2014-07-041-2/+2
| | | | llvm-svn: 212361
* Ignore llvm.* globals.Rafael Espindola2014-07-041-6/+3
| | | | | | | It is not clear if llvm.global_ctors should or should not be in llvm.metadata, but in practice it is not and we need to ignore it for LTO. llvm-svn: 212351
* Implement LTOModule on top of IRObjectFile.Rafael Espindola2014-07-041-14/+12
| | | | | | | | | | | | | IRObjectFile provides all the logic for producing mangled names and getting symbols from inline assembly. LTOModule then adds logic for linking specific tasks, like constructing llvm.compiler_user or extracting linker options from the bitcode. The rule of the thumb is that IRObjectFile has the functionality that is needed by both LTO and llvm-ar. llvm-svn: 212349
* Mark intrinsic functions as llvm-specific.Rafael Espindola2014-07-041-0/+5
| | | | llvm-svn: 212347
* Don't include llvm.metadata variables in archive symbol tables.Rafael Espindola2014-07-041-0/+5
| | | | llvm-svn: 212344
* Move createIRObjectFile to the IRObjectFile class and return the concrete type.Rafael Espindola2014-07-031-1/+1
| | | | llvm-svn: 212301
* Add support for inline asm symbols to IRObjectFile.Rafael Espindola2014-07-031-21/+130
| | | | | | This also enables it in llvm-nm so that it can be tested. llvm-svn: 212282
* Pass a unique_ptr<MemoryBuffer> to the constructors in the Binary hierarchy.Rafael Espindola2014-06-241-8/+9
| | | | | | | Once the objects are constructed, they own the buffer. Passing a unique_ptr makes that clear. llvm-svn: 211595
* Make ObjectFile and BitcodeReader always own the MemoryBuffer.Rafael Espindola2014-06-231-8/+10
| | | | | | | | | | This allows us to just use a std::unique_ptr to store the pointer to the buffer. The flip side is that they have to support releasing the buffer back to the caller. Overall this looks like a more efficient and less brittle api. llvm-svn: 211542
* Change IRObjectFile to parse the bitcode lazily.Rafael Espindola2014-06-181-2/+13
| | | | | | | The main point of this class is to provide a cheap object interface to a bitcode file, so it has to be as lazy as possible. llvm-svn: 211207
* Remove 'using std::errro_code' from lib.Rafael Espindola2014-06-131-5/+4
| | | | llvm-svn: 210871
* Don't use 'using std::error_code' in include/llvm.Rafael Espindola2014-06-121-0/+1
| | | | | | This should make sure that most new uses use the std prefix. llvm-svn: 210835
* Remove the linker_private and linker_private_weak linkages.Rafael Espindola2014-03-131-2/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | These linkages were introduced some time ago, but it was never very clear what exactly their semantics were or what they should be used for. Some investigation found these uses: * utf-16 strings in clang. * non-unnamed_addr strings produced by the sanitizers. It turns out they were just working around a more fundamental problem. For some sections a MachO linker needs a symbol in order to split the section into atoms, and llvm had no idea that was the case. I fixed that in r201700 and it is now safe to use the private linkage. When the object ends up in a section that requires symbols, llvm will use a 'l' prefix instead of a 'L' prefix and things just work. With that, these linkages were already dead, but there was a potential future user in the objc metadata information. I am still looking at CGObjcMac.cpp, but at this point I am convinced that linker_private and linker_private_weak are not what they need. The objc uses are currently split in * Regular symbols (no '\01' prefix). LLVM already directly provides whatever semantics they need. * Uses of a private name (start with "\01L" or "\01l") and private linkage. We can drop the "\01L" and "\01l" prefixes as soon as llvm agrees with clang on L being ok or not for a given section. I have two patches in code review for this. * Uses of private name and weak linkage. The last case is the one that one could think would fit one of these linkages. That is not the case. The semantics are * the linker will merge these symbol by *name*. * the linker will hide them in the final DSO. Given that the merging is done by name, any of the private (or internal) linkages would be a bad match. They allow llvm to rename the symbols, and that is really not what we want. From the llvm point of view, these objects should really be (linkonce|weak)(_odr)?. For now, just keeping the "\01l" prefix is probably the best for these symbols. If we one day want to have a more direct support in llvm, IMHO what we should add is not a linkage, it is just a hidden_symbol attribute. It would be applicable to multiple linkages. For example, on weak it would produce the current behavior we have for objc metadata. On internal, it would be equivalent to private (and we should then remove private). llvm-svn: 203866
* Replace OwningPtr<T> with std::unique_ptr<T>.Ahmed Charles2014-03-061-1/+1
| | | | | | | | | | This compiles with no changes to clang/lld/lldb with MSVC and includes overloads to various functions which are used by those projects and llvm which have OwningPtr's as parameters. This should allow out of tree projects some time to move. There are also no changes to libs/Target, which should help out of tree targets have time to move, if necessary. llvm-svn: 203083
* [C++11] Replace OwningPtr::take() with OwningPtr::release().Ahmed Charles2014-03-051-1/+1
| | | | llvm-svn: 202957
* Now that it is possible, use the mangler in IRObjectFile.Rafael Espindola2014-02-281-2/+14
| | | | | | A really simple patch marks the end of a lot of yak shaving :-) llvm-svn: 202463
* Add missing include.Rafael Espindola2014-02-211-0/+1
| | | | | | Should fix the bots. llvm-svn: 201882
* Add a SymbolicFile interface between Binary and ObjectFile.Rafael Espindola2014-02-211-0/+139
This interface allows IRObjectFile to be implemented without having dummy methods for all section and segment related methods. Both llvm-ar and llvm-nm are changed to use it. Unfortunately the mangler is still not plugged in since it requires some refactoring to make a Module hold a DataLayout. llvm-svn: 201881
OpenPOWER on IntegriCloud