summaryrefslogtreecommitdiffstats
path: root/llvm/lib/LTO
Commit message (Collapse)AuthorAgeFilesLines
...
* Use std::unique_ptr to manage memory. No functionality change.Rafael Espindola2014-07-031-13/+14
| | | | llvm-svn: 212299
* LTO depends on Object now.Rafael Espindola2014-07-031-1/+1
| | | | | | | Fixes the build with only the ARM backend enabled. For some reason some other backend was pulling Object and this went unnoticed. llvm-svn: 212288
* 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
* Revert "Introduce a string_ostream string builder facilty"Alp Toker2014-06-261-6/+5
| | | | | | Temporarily back out commits r211749, r211752 and r211754. llvm-svn: 211814
* Introduce a string_ostream string builder faciltyAlp Toker2014-06-261-5/+6
| | | | | | | | | | | | | | | | | | | | string_ostream is a safe and efficient string builder that combines opaque stack storage with a built-in ostream interface. small_string_ostream<bytes> additionally permits an explicit stack storage size other than the default 128 bytes to be provided. Beyond that, storage is transferred to the heap. This convenient class can be used in most places an std::string+raw_string_ostream pair or SmallString<>+raw_svector_ostream pair would previously have been used, in order to guarantee consistent access without byte truncation. The patch also converts much of LLVM to use the new facility. These changes include several probable bug fixes for truncated output, a programming error that's no longer possible with the new interface. llvm-svn: 211749
* 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
* Use the assignment operator.Rafael Espindola2014-06-191-22/+1
| | | | | | No functionality change. llvm-svn: 211319
* Set missing options in LTOCodeGenerator::setTargetOptions.Rafael Espindola2014-06-191-0/+5
| | | | | | Patch by Tom Roeder, I just added the test. llvm-svn: 211317
* Remove 'using std::errro_code' from lib.Rafael Espindola2014-06-132-7/+6
| | | | llvm-svn: 210871
* Don't use 'using std::error_code' in include/llvm.Rafael Espindola2014-06-122-0/+2
| | | | | | This should make sure that most new uses use the std prefix. llvm-svn: 210835
* Remove system_error.h.Rafael Espindola2014-06-122-2/+2
| | | | | | | 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
* Build fix: remove initializeJumpInstrTablesPass() call from LTOAlp Toker2014-06-071-1/+0
| | | | | | | | | | | | | | | This was incurring an unsatisfied dependency on CodeGen from LTO breaking shared builds: Undefined symbols for architecture x86_64: "llvm::initializeJumpInstrTablesPass(llvm::PassRegistry&)", referenced from: llvm::LTOCodeGenerator::initializeLTOPasses() in LTOCodeGenerator.cpp.o ld: symbol(s) not found for architecture x86_64 clang: error: linker command failed with exit code 1 (use -v to see invocation) Removed as a temporary measure pending feedback from the author. llvm-svn: 210400
* Add a new attribute called 'jumptable' that creates jump-instruction tables ↵Tom Roeder2014-06-051-0/+1
| | | | | | | | | | | | for functions marked with this attribute. It includes a pass that rewrites all indirect calls to jumptable functions to pass through these tables. This also adds backend support for generating the jump-instruction tables on ARM and X86. Note that since the jumptable attribute creates a second function pointer for a function, any function marked with jumptable must also be marked with unnamed_addr. llvm-svn: 210280
* 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-242-2/+4
| | | | | | | | | | | | | | | 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
* Use a range loop.Rafael Espindola2014-05-051-3/+1
| | | | llvm-svn: 207996
* Trivial simplification. No functionality change.Rafael Espindola2014-05-051-1/+1
| | | | llvm-svn: 207967
* Rename member variable to try to fix the bots.Rafael Espindola2014-05-031-7/+7
| | | | llvm-svn: 207915
* Add an -mattr option to the gold plugin to support subtarget features in LTOTom Roeder2014-04-251-2/+3
| | | | | | | | | | This adds support for an -mattr option to the gold plugin and to llvm-lto. This allows the caller to specify details of the subtarget architecture, like +aes, or +ssse3 on x86. Note that this requires a change to the include/llvm-c/lto.h interface: it adds a function lto_codegen_set_attr and it increments the version of the interface. llvm-svn: 207279
* 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
* verify-di: Implement DebugInfoVerifierDuncan P. N. Exon Smith2014-04-151-0/+3
| | | | | | | | | | | | | | | | | | | | | Implement DebugInfoVerifier, which steals verification relying on DebugInfoFinder from Verifier. - Adds LegacyDebugInfoVerifierPassPass, a ModulePass which wraps DebugInfoVerifier. Uses -verify-di command-line flag. - Change verifyModule() to invoke DebugInfoVerifier as well as Verifier. - Add a call to createDebugInfoVerifierPass() wherever there was a call to createVerifierPass(). This implementation as a module pass should sidestep efficiency issues, allowing us to turn debug info verification back on. <rdar://problem/15500563> llvm-svn: 206300
* [C++11] More 'nullptr' conversion. In some cases just using a boolean check ↵Craig Topper2014-04-152-22/+22
| | | | | | instead of comparing to nullptr. llvm-svn: 206252
* Teach llvm-lto to respect the given RelocModel.James Molloy2014-04-141-1/+5
| | | | | | Patch by Nick Tomlinson! llvm-svn: 206177
* Move the segmented stack switch to a function attributeReid Kleckner2014-04-101-1/+0
| | | | | | | | | This removes the -segmented-stacks command line flag in favor of a per-function "split-stack" attribute. Patch by Luqman Aden and Alex Crichton! llvm-svn: 205997
* Revert "Reapply "LTO: add API to set strategy for -internalize""Duncan P. N. Exon Smith2014-04-021-17/+3
| | | | | | | | | | | This reverts commit r199244. Conflicts: include/llvm-c/lto.h include/llvm/LTO/LTOCodeGenerator.h lib/LTO/LTOCodeGenerator.cpp llvm-svn: 205471
* 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-292-0/+4
| | | | | | | | | | | | 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
* Remove the linker_private and linker_private_weak linkages.Rafael Espindola2014-03-131-4/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* [C++11] Add 'override' keyword to virtual methods that override their base ↵Craig Topper2014-03-081-45/+46
| | | | | | class. llvm-svn: 203344
* Replace OwningPtr<T> with std::unique_ptr<T>.Ahmed Charles2014-03-062-17/+15
| | | | | | | | | | 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
* [Layering] Sink Linker.h into a Linker subdirectory to make itChandler Carruth2014-03-061-1/+1
| | | | | | consistent with every other sub-library header in LLVM. llvm-svn: 203065
* [C++11] Replace OwningPtr::take() with OwningPtr::release().Ahmed Charles2014-03-052-6/+6
| | | | llvm-svn: 202957
* [cleanup] Re-sort all the includes with utils/sort_includes.py.Chandler Carruth2014-03-041-1/+1
| | | | llvm-svn: 202811
* Add 'remark' diagnostic type in LLVMTobias Grosser2014-02-281-0/+3
| | | | | | | | | | | | A 'remark' is information that is not an error or a warning, but rather some additional information provided to the user. In contrast to a 'note' a 'remark' is an independent diagnostic, whereas a 'note' always depends on another diagnostic. A typical use case for remark nodes is information provided to the user, e.g. information provided by the vectorizer about loops that have been vectorized. llvm-svn: 202474
* Use DataLayout from the module when easily available.Rafael Espindola2014-02-251-2/+3
| | | | | | | | | | | | | | | | | Eventually DataLayoutPass should go away, but for now that is the only easy way to get a DataLayout in some APIs. This patch only changes the ones that have easy access to a Module. One interesting issue with sometimes using DataLayoutPass and sometimes fetching it from the Module is that we have to make sure they are equivalent. We can get most of the way there by always constructing the pass with a Module. In fact, the pass could be changed to point to an external DataLayout instead of owning one to make this stricter. Unfortunately, the C api passes a DataLayout, so it has to be up to the caller to make sure the pass and the module are in sync. llvm-svn: 202204
* Make DataLayout a plain object, not a pass.Rafael Espindola2014-02-251-2/+2
| | | | | | | Instead, have a DataLayoutPass that holds one. This will allow parts of LLVM don't don't handle passes to also use DataLayout. llvm-svn: 202168
* Replace the F_Binary flag with a F_Text one.Rafael Espindola2014-02-241-1/+1
| | | | | | | | | After this I will set the default back to F_None. The advantage is that before this patch forgetting to set F_Binary would corrupt a file on windows. Forgetting to set F_Text produces one that cannot be read in notepad, which is a better failure mode :-) llvm-svn: 202052
* move getNameWithPrefix and getSymbol to TargetMachine.Rafael Espindola2014-02-192-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
OpenPOWER on IntegriCloud