summaryrefslogtreecommitdiffstats
path: root/llvm/lib/LTO/LTOModule.cpp
Commit message (Collapse)AuthorAgeFilesLines
* LTO: Lazy-load LTOModule in local contextsDuncan P. N. Exon Smith2014-12-171-7/+23
| | | | | | | | | | | | | | | | | | | | | | | | | Start lazy-loading `LTOModule`s that own their contexts. These can only really be used for parsing symbols, so its unnecessary to ever materialize their functions. I looked into using `IRObjectFile::create()` and optionally calling `materializAllPermanently()` afterwards, but this turned out to be awkward. - The default target triple and data layout logic needs to happen *before* the call to `IRObjectFile::IRObjectFile()`, but after `Module` was created. - I tried passing a lambda in to do the module initialization, but this seemed to require threading the error message from `TargetRegistry::lookupTarget()` through `std::error_code`. - I also looked at setting `errMsg` directly from within the lambda, but this didn't look any better. (I guess there's a reason we weren't already using that function.) llvm-svn: 224466
* IR: Split Metadata from ValueDuncan P. N. Exon Smith2014-12-091-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Split `Metadata` away from the `Value` class hierarchy, as part of PR21532. Assembly and bitcode changes are in the wings, but this is the bulk of the change for the IR C++ API. I have a follow-up patch prepared for `clang`. If this breaks other sub-projects, I apologize in advance :(. Help me compile it on Darwin I'll try to fix it. FWIW, the errors should be easy to fix, so it may be simpler to just fix it yourself. This breaks the build for all metadata-related code that's out-of-tree. Rest assured the transition is mechanical and the compiler should catch almost all of the problems. Here's a quick guide for updating your code: - `Metadata` is the root of a class hierarchy with three main classes: `MDNode`, `MDString`, and `ValueAsMetadata`. It is distinct from the `Value` class hierarchy. It is typeless -- i.e., instances do *not* have a `Type`. - `MDNode`'s operands are all `Metadata *` (instead of `Value *`). - `TrackingVH<MDNode>` and `WeakVH` referring to metadata can be replaced with `TrackingMDNodeRef` and `TrackingMDRef`, respectively. If you're referring solely to resolved `MDNode`s -- post graph construction -- just use `MDNode*`. - `MDNode` (and the rest of `Metadata`) have only limited support for `replaceAllUsesWith()`. As long as an `MDNode` is pointing at a forward declaration -- the result of `MDNode::getTemporary()` -- it maintains a side map of its uses and can RAUW itself. Once the forward declarations are fully resolved RAUW support is dropped on the ground. This means that uniquing collisions on changing operands cause nodes to become "distinct". (This already happened fairly commonly, whenever an operand went to null.) If you're constructing complex (non self-reference) `MDNode` cycles, you need to call `MDNode::resolveCycles()` on each node (or on a top-level node that somehow references all of the nodes). Also, don't do that. Metadata cycles (and the RAUW machinery needed to construct them) are expensive. - An `MDNode` can only refer to a `Constant` through a bridge called `ConstantAsMetadata` (one of the subclasses of `ValueAsMetadata`). As a side effect, accessing an operand of an `MDNode` that is known to be, e.g., `ConstantInt`, takes three steps: first, cast from `Metadata` to `ConstantAsMetadata`; second, extract the `Constant`; third, cast down to `ConstantInt`. The eventual goal is to introduce `MDInt`/`MDFloat`/etc. and have metadata schema owners transition away from using `Constant`s when the type isn't important (and they don't care about referring to `GlobalValue`s). In the meantime, I've added transitional API to the `mdconst` namespace that matches semantics with the old code, in order to avoid adding the error-prone three-step equivalent to every call site. If your old code was: MDNode *N = foo(); bar(isa <ConstantInt>(N->getOperand(0))); baz(cast <ConstantInt>(N->getOperand(1))); bak(cast_or_null <ConstantInt>(N->getOperand(2))); bat(dyn_cast <ConstantInt>(N->getOperand(3))); bay(dyn_cast_or_null<ConstantInt>(N->getOperand(4))); you can trivially match its semantics with: MDNode *N = foo(); bar(mdconst::hasa <ConstantInt>(N->getOperand(0))); baz(mdconst::extract <ConstantInt>(N->getOperand(1))); bak(mdconst::extract_or_null <ConstantInt>(N->getOperand(2))); bat(mdconst::dyn_extract <ConstantInt>(N->getOperand(3))); bay(mdconst::dyn_extract_or_null<ConstantInt>(N->getOperand(4))); and when you transition your metadata schema to `MDInt`: MDNode *N = foo(); bar(isa <MDInt>(N->getOperand(0))); baz(cast <MDInt>(N->getOperand(1))); bak(cast_or_null <MDInt>(N->getOperand(2))); bat(dyn_cast <MDInt>(N->getOperand(3))); bay(dyn_cast_or_null<MDInt>(N->getOperand(4))); - A `CallInst` -- specifically, intrinsic instructions -- can refer to metadata through a bridge called `MetadataAsValue`. This is a subclass of `Value` where `getType()->isMetadataTy()`. `MetadataAsValue` is the *only* class that can legally refer to a `LocalAsMetadata`, which is a bridged form of non-`Constant` values like `Argument` and `Instruction`. It can also refer to any other `Metadata` subclass. (I'll break all your testcases in a follow-up commit, when I propagate this change to assembly.) llvm-svn: 223802
* Remove StringMap::GetOrCreateValue in favor of StringMap::insertDavid Blaikie2014-11-191-50/+38
| | | | | | | | | | | | | | Having two ways to do this doesn't seem terribly helpful and consistently using the insert version (which we already has) seems like it'll make the code easier to understand to anyone working with standard data structures. (I also updated many references to the Entry's key and value to use first() and second instead of getKey{Data,Length,} and get/setValue - for similar consistency) Also removes the GetOrCreateValue functions so there's less surface area to StringMap to fix/improve/change/accommodate move semantics, etc. llvm-svn: 222319
* libLTO: Allow LTOModule to own a contextDuncan P. N. Exon Smith2014-11-111-8/+43
| | | | llvm-svn: 221728
* LTO: introduce object file-based on-disk module format.Peter Collingbourne2014-09-181-13/+30
| | | | | | | | | | | | | | | | | | 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
* Return a std::unique_ptr when creating a new MemoryBuffer.Rafael Espindola2014-08-271-2/+1
| | | | llvm-svn: 216583
* Pass a MemoryBufferRef when we can avoid taking ownership.Rafael Espindola2014-08-261-9/+3
| | | | | | | | | | | | | 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
* Simplify LTOModule::makeLTOModule a bit. NFC.Rafael Espindola2014-08-261-3/+1
| | | | | | | Just call parseBitcodeFile instead of getLazyBitcodeModule followed by materializeAllPermanently. llvm-svn: 216461
* Silencing a -Wcast-qual warning. NFC.Aaron Ballman2014-08-201-1/+1
| | | | llvm-svn: 216068
* Don't own the buffer in object::Binary.Rafael Espindola2014-08-191-9/+17
| | | | | | | | | | | | | | | | | | | | | | | | | 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
* Return a std::uinque_ptr. Every caller was already using one.Rafael Espindola2014-08-171-3/+4
| | | | llvm-svn: 215858
* Remove the TargetMachine forwards for TargetSubtargetInfo basedEric Christopher2014-08-041-3/+6
| | | | | | information and update all callers. No functional change. llvm-svn: 214781
* Refactor duplicated code.Rafael Espindola2014-07-301-23/+2
| | | | llvm-svn: 214328
* Add the missing hasLinkOnceODRLinkage predicate.Rafael Espindola2014-07-301-3/+1
| | | | llvm-svn: 214312
* AArch64: remove arm64 triple enumerator.Tim Northover2014-07-231-2/+1
| | | | | | | | | | | | Having both Triple::arm64 and Triple::aarch64 is extremely confusing, and invites bugs where only one is checked. In reality, the only legitimate difference between the two (arm64 usually means iOS) is also present in the OS part of the triple and that's what should be checked. We still parse the "arm64" triple, just canonicalise it to Triple::aarch64, so there aren't any LLVM-side test changes. llvm-svn: 213743
* Update the MemoryBuffer API to use ErrorOr.Rafael Espindola2014-07-061-9/+10
| | | | llvm-svn: 212405
* Revert "Convert a few std::strings to StringRef."Rafael Espindola2014-07-041-2/+2
| | | | | | | | | This reverts commit r212342. We can get a StringRef into the current Record, but not one in the bitcode itself since the string is compressed in it. llvm-svn: 212356
* Ignore llvm specific symbols in the LTOModule.Rafael Espindola2014-07-041-0/+3
| | | | | | | | | | These are the llvm.* globals and functions. I don't think it is possible to test this directly since llvm-lto is not a full linker and will not report duplicated symbols, but this fixes bootstrap with gold and lto enabled. llvm-svn: 212354
* Implement LTOModule on top of IRObjectFile.Rafael Espindola2014-07-041-126/+75
| | | | | | | | | | | | | 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
* Avoid mangling names twice. No functionality change.Rafael Espindola2014-07-041-18/+24
| | | | llvm-svn: 212348
* Convert a few std::strings to StringRef.Rafael Espindola2014-07-041-2/+2
| | | | llvm-svn: 212342
* Fix prefix comparison from r212308Alp Toker2014-07-041-1/+2
| | | | llvm-svn: 212310
* Sink undesirable LTO functions into the old C APIAlp Toker2014-07-041-24/+3
| | | | | | | | | We want to encourage users of the C++ LTO API to reuse memory buffers instead of repeatedly opening and reading the same file contents. This reverts commit r212305 and implements a tidier scheme. llvm-svn: 212308
* Modify LTOModule::isTargetMatch to take a StringRef instead of a MemoryBuffer.Peter Collingbourne2014-07-031-8/+8
| | | | llvm-svn: 212305
* LTO: rename the various makeLTOModule overloads.Peter Collingbourne2014-07-031-16/+13
| | | | | | | | | This rename makes it easier to identify the specific overload being called in each particular case and makes future refactorings easier. Differential Revision: http://reviews.llvm.org/D4370 llvm-svn: 212302
* Use std::unique_ptr to manage memory. No functionality change.Rafael Espindola2014-07-031-13/+14
| | | | llvm-svn: 212299
* Add support for inline asm symbols to IRObjectFile.Rafael Espindola2014-07-031-100/+1
| | | | | | This also enables it in llvm-nm so that it can be tested. llvm-svn: 212282
* Use a range loop. No functionality change.Rafael Espindola2014-06-281-4/+3
| | | | llvm-svn: 211986
* Merge the used symbol scanning of MCObjectStreamer and RecordStreamer.Rafael Espindola2014-06-251-6/+2
| | | | | | This completes the refactoring of RecordStreamer. llvm-svn: 211727
* Move expression visitation logic up to MCStreamer.Rafael Espindola2014-06-251-27/+4
| | | | | | Remove the duplicate from MCRecordStreamer. No functionality change. llvm-svn: 211714
* Move some trivial methods up to MCStreamer.Rafael Espindola2014-06-251-35/+0
| | | | | | This saves some duplicated boilerplate in RecordStreamer and NullStreamer. llvm-svn: 211653
* Simplify the handling of .cfi_endproc.Rafael Espindola2014-06-251-3/+0
| | | | | | No functionality change. llvm-svn: 211651
* Simplify EmitLabel.Rafael Espindola2014-06-241-1/+1
| | | | | | | All the "real" streamers were already calling to MCStreamer::EmitLabel to do part of the work. llvm-svn: 211646
* Print a=b as an assignment.Rafael Espindola2014-06-241-3/+0
| | | | | | | | | | | In assembly the expression a=b is parsed as an assignment, so it should be printed as one. This remove a truly horrible hack for producing a label with "a=.". It would be used by codegen but would never be reached by the asm parser. Sorry I missed this when it was first committed. llvm-svn: 211639
* Remove 'using std::errro_code' from lib.Rafael Espindola2014-06-131-4/+3
| | | | 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 system_error.h.Rafael Espindola2014-06-121-1/+1
| | | | | | | This is a minimal change to remove the header. I will remove the occurrences of "using std::error_code" in a followup patch. llvm-svn: 210803
* Allow alias to point to an arbitrary ConstantExpr.Rafael Espindola2014-06-031-3/+4
| | | | | | | | | | | | | | | | | | | | | This patch changes GlobalAlias to point to an arbitrary ConstantExpr and it is up to MC (or the system assembler) to decide if that expression is valid or not. This reduces our ability to diagnose invalid uses and how early we can spot them, but it also lets us do things like @test5 = alias inttoptr(i32 sub (i32 ptrtoint (i32* @test2 to i32), i32 ptrtoint (i32* @bar to i32)) to i32*) An important implication of this patch is that the notion of aliased global doesn't exist any more. The alias has to encode the information needed to access it in its metadata (linkage, visibility, type, etc). Another consequence to notice is that getSection has to return a "const char *". It could return a NullTerminatedStringRef if there was such a thing, but when that was proposed the decision was to just uses "const char*" for that. llvm-svn: 210062
* AArch64/ARM64: move ARM64 into AArch64's placeTim Northover2014-05-241-1/+2
| | | | | | | | | | | | | | | This commit starts with a "git mv ARM64 AArch64" and continues out from there, renaming the C++ classes, intrinsics, and other target-local objects for consistency. "ARM64" test directories are also moved, and tests that began their life in ARM64 use an arm64 triple, those from AArch64 use an aarch64 triple. Both should be equivalent though. This finishes the AArch64 merge, and everyone should feel free to continue committing as normal now. llvm-svn: 209577
* Aliases are always definition, delete dead code.Rafael Espindola2014-05-231-8/+2
| | | | | | While at it, use a range loop. llvm-svn: 209519
* Delete getAliasedGlobal.Rafael Espindola2014-05-161-1/+1
| | | | llvm-svn: 209040
* Move EmitDwarfAdvanceLineAddr and EmitDwarfAdvanceFrameAddr to the obj streamer.Rafael Espindola2014-05-121-3/+0
| | | | | | This lets us delete the MCAsmStreamer implementation. No functionality change. llvm-svn: 208570
* LTO: Check local linkage firstDuncan P. N. Exon Smith2014-05-071-5/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Since visibility is meaningless for symbols with local linkage, check local linkage before visibility when setting symbol attributes. When linkage is `internal` and the visibility is `hidden`, the exposed attribute is now `LTO_SYMBOL_SCOPE_INTERNAL` instead of `LTO_SYMBOL_SCOPE_HIDDEN`. Although the bitfield allows *both* to be specified, the combination is nonsense anyway. Given changes (in progress) to drop visibility when a symbol has local linkage, this almost has no functionality change: it's mostly a cleanup to clarify the logic. The exception is when something has `appending` linkage. Before this change, such symbols would be advertised as `LTO_SYMBOL_SCOPE_INTERNAL`; now, they'll be given `LTO_SYMBOL_SCOPE_COMMON`. Unfortunately this is really awkward to test. This only changes what we advertise to linkers (before running LTO), not what the final object looks like. In theory I could add `DEBUG` output to `llvm-lto` (and test with "REQUIRES: asserts"), but follow-up commits to disallow `internal hidden` simplify this anyway. <rdar://problem/16141113> llvm-svn: 208261
* Trivial simplification. No functionality change.Rafael Espindola2014-05-051-1/+1
| | | | llvm-svn: 207967
* Create MCTargetOptions.Evgeniy Stepanov2014-04-231-1/+2
| | | | | | | | | For now it contains a single flag, SanitizeAddress, which enables AddressSanitizer instrumentation of inline assembly. Patch by Yuri Gorshenin. llvm-svn: 206971
* Fix the assembler to print a better relocatable expression errorKevin Enderby2014-04-221-1/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | diagnostic that includes location information. Currently if one has this assembly: .quad (0x1234 + (4 * SOME_VALUE)) where SOME_VALUE is undefined ones gets the less than useful error message with no location information: % clang -c x.s clang -cc1as: fatal error: error in backend: expected relocatable expression With this fix one now gets a more useful error message with location information: % clang -c x.s x.s:5:8: error: expected relocatable expression .quad (0x1234 + (4 * SOME_VALUE)) ^ To do this I plumbed the SMLoc through the MCObjectStreamer EmitValue() and EmitValueImpl() interfaces so it could be used when creating the MCFixup. rdar://12391022 llvm-svn: 206906
* Remove some empty statementsAlp Toker2014-04-191-1/+1
| | | | | | Cleanup only. llvm-svn: 206710
* [C++11] More 'nullptr' conversion. In some cases just using a boolean check ↵Craig Topper2014-04-151-9/+9
| | | | | | instead of comparing to nullptr. llvm-svn: 206252
* This patch fixes LTO's RecordStreamer so that it records symbols in the MCExprTom Roeder2014-03-311-0/+1
| | | | | | | | | | | part of an asm .symver directive as being used. This prevents referenced functions from being internalized and deleted. Without the patch to LTOModule.cpp, the test case will produce the error: LLVM ERROR: A @@ version cannot be undefined. llvm-svn: 205221
* ARM64: initial backend importTim Northover2014-03-291-0/+2
| | | | | | | | | | | | This adds a second implementation of the AArch64 architecture to LLVM, accessible in parallel via the "arm64" triple. The plan over the coming weeks & months is to merge the two into a single backend, during which time thorough code review should naturally occur. Everything will be easier with the target in-tree though, hence this commit. llvm-svn: 205090
OpenPOWER on IntegriCloud