summaryrefslogtreecommitdiffstats
path: root/llvm/test/LTO/X86
Commit message (Collapse)AuthorAgeFilesLines
...
* llvm-lto2: Move the LTO::run() action behind a subcommand.Peter Collingbourne2017-04-112-2/+2
| | | | | | | | | | | | | Move LTO::run() to a "run" subcommand so that we can introduce new subcommands for testing different parts of the LTO implementation. This doesn't use llvm::cl subcommands because it doesn't appear to be currently possible to pass an argument not associated with a subcommand to a subcommand (e.g. -lto-use-new-pm, -mcpu=yonah). Differential Revision: https://reviews.llvm.org/D31410 llvm-svn: 299967
* Perform symbol binding for .symver versioned symbolsTeresa Johnson2017-03-092-6/+67
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: In a .symver assembler directive like: .symver name, name2@@nodename "name2@@nodename" should get the same symbol binding as "name". While the ELF object writer is updating the symbol binding for .symver aliases before emitting the object file, not doing so when the module inline assembly is handled by the RecordStreamer is causing the wrong behavior in *LTO mode. E.g. when "name" is global, "name2@@nodename" must also be marked as global. Otherwise, the symbol is skipped when iterating over the LTO InputFile symbols (InputFile::Symbol::shouldSkip). So, for example, when performing any *LTO via the gold-plugin, the versioned symbol definition is not recorded by the plugin and passed back to the linker. If the object was in an archive, and there were no other symbols needed from that object, the object would not be included in the final link and references to the versioned symbol are undefined. The llvm-lto2 tests added will give an error about an unused symbol resolution without the fix. Reviewers: rafael, pcc Reviewed By: pcc Subscribers: mehdi_amini, llvm-commits Differential Revision: https://reviews.llvm.org/D30485 llvm-svn: 297332
* Add a testcase for r297072.Adrian Prantl2017-03-071-0/+56
| | | | | | | Check that missing debug locations on inlinable calls are a recoverable error. llvm-svn: 297113
* Implement intrinsic mangling for literal struct types.Daniel Berlin2017-02-151-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Fixes PR 31921 Summary: Predicateinfo requires an ugly workaround to try to avoid literal struct types due to the intrinsic mangling not being implemented. This workaround actually does not work in all cases (you can hit the assert by bootstrapping with -print-predicateinfo), and can't be made to work without DFS'ing the type (IE copying getMangledStr and using a version that detects if it would crash). Rather than do that, i just implemented the mangling. It seems simple, since they are unified structurally. Looking at the overloaded-mangling testcase we have, it actually turns out the gc intrinsics will *also* crash if you try to use a literal struct. Thus, the testcase added fails before this patch, and works after, without needing to resort to predicateinfo. Reviewers: chandlerc, davide Subscribers: llvm-commits, sanjoy Differential Revision: https://reviews.llvm.org/D29925 llvm-svn: 295253
* [LTO] Simplify this test quite a bit, @func2 is unused/unneeded.Davide Italiano2017-02-121-42/+0
| | | | llvm-svn: 294884
* [tests] Be explicit about the files we want to remove.Davide Italiano2017-02-102-2/+2
| | | | | | Hopefully Windows will stop whining after this change. llvm-svn: 294801
* [LTO] Make these tests robust across multiple iterations.Davide Italiano2017-02-102-0/+2
| | | | | | Same as r294784, but for regular LTO. llvm-svn: 294789
* Renumber testcase metadata nodes after r290153.Adrian Prantl2016-12-222-38/+37
| | | | | | | | | | | | | This patch renumbers the metadata nodes in debug info testcases after https://reviews.llvm.org/D26769. This is a separate patch because it causes so much churn. This was implemented with a python script that pipes the testcases through llvm-as - | llvm-dis - and then goes through the original and new output side-by side to insert all comments at a close-enough location. Differential Revision: https://reviews.llvm.org/D27765 llvm-svn: 290292
* [IR] Remove the DIExpression field from DIGlobalVariable.Adrian Prantl2016-12-202-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch implements PR31013 by introducing a DIGlobalVariableExpression that holds a pair of DIGlobalVariable and DIExpression. Currently, DIGlobalVariables holds a DIExpression. This is not the best way to model this: (1) The DIGlobalVariable should describe the source level variable, not how to get to its location. (2) It makes it unsafe/hard to update the expressions when we call replaceExpression on the DIGLobalVariable. (3) It makes it impossible to represent a global variable that is in more than one location (e.g., a variable with multiple DW_OP_LLVM_fragment-s). We also moved away from attaching the DIExpression to DILocalVariable for the same reasons. This reapplies r289902 with additional testcase upgrades and a change to the Bitcode record for DIGlobalVariable, that makes upgrading the old format unambiguous also for variables without DIExpressions. <rdar://problem/29250149> https://llvm.org/bugs/show_bug.cgi?id=31013 Differential Revision: https://reviews.llvm.org/D26769 llvm-svn: 290153
* Revert "[IR] Remove the DIExpression field from DIGlobalVariable."Adrian Prantl2016-12-162-2/+2
| | | | | | | | | | | | | | | | | This reverts commit 289920 (again). I forgot to implement a Bitcode upgrade for the case where a DIGlobalVariable has not DIExpression. Unfortunately it is not possible to safely upgrade these variables without adding a flag to the bitcode record indicating which version they are. My plan of record is to roll the planned follow-up patch that adds a unit: field to DIGlobalVariable into this patch before recomitting. This way we only need one Bitcode upgrade for both changes (with a version flag in the bitcode record to safely distinguish the record formats). Sorry for the churn! llvm-svn: 289982
* [IR] Remove the DIExpression field from DIGlobalVariable.Adrian Prantl2016-12-162-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch implements PR31013 by introducing a DIGlobalVariableExpression that holds a pair of DIGlobalVariable and DIExpression. Currently, DIGlobalVariables holds a DIExpression. This is not the best way to model this: (1) The DIGlobalVariable should describe the source level variable, not how to get to its location. (2) It makes it unsafe/hard to update the expressions when we call replaceExpression on the DIGLobalVariable. (3) It makes it impossible to represent a global variable that is in more than one location (e.g., a variable with multiple DW_OP_LLVM_fragment-s). We also moved away from attaching the DIExpression to DILocalVariable for the same reasons. This reapplies r289902 with additional testcase upgrades. <rdar://problem/29250149> https://llvm.org/bugs/show_bug.cgi?id=31013 Differential Revision: https://reviews.llvm.org/D26769 llvm-svn: 289920
* Revert "[IR] Remove the DIExpression field from DIGlobalVariable."Adrian Prantl2016-12-162-2/+2
| | | | | | This reverts commit 289902 while investigating bot berakage. llvm-svn: 289906
* [IR] Remove the DIExpression field from DIGlobalVariable.Adrian Prantl2016-12-162-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | This patch implements PR31013 by introducing a DIGlobalVariableExpression that holds a pair of DIGlobalVariable and DIExpression. Currently, DIGlobalVariables holds a DIExpression. This is not the best way to model this: (1) The DIGlobalVariable should describe the source level variable, not how to get to its location. (2) It makes it unsafe/hard to update the expressions when we call replaceExpression on the DIGLobalVariable. (3) It makes it impossible to represent a global variable that is in more than one location (e.g., a variable with multiple DW_OP_LLVM_fragment-s). We also moved away from attaching the DIExpression to DILocalVariable for the same reasons. <rdar://problem/29250149> https://llvm.org/bugs/show_bug.cgi?id=31013 Differential Revision: https://reviews.llvm.org/D26769 llvm-svn: 289902
* [LTO] Reject modules without datalayout.Davide Italiano2016-12-144-2/+4
| | | | | | | | | | | Also, udpate the ~60 failing tests in the tree which did not contain a valid datalayout. This fixes PR31123. lld will be updated in a following patch, immediately after this is committed. Differential Revision: https://reviews.llvm.org/D27082 llvm-svn: 289719
* [LTOs] Allow generation of hotness informationAdam Nemet2016-12-021-0/+77
| | | | | | | | The flag is passed by the clang driver. Differential Revision: https://reviews.llvm.org/D27331 llvm-svn: 288519
* Make LTO opt-remarks tests matching stricterAdam Nemet2016-12-021-9/+9
| | | | | | This ensures that we don't generate the hotness attribute by default. llvm-svn: 288518
* Rename option to -lto-pass-remarks-outputAdam Nemet2016-11-221-1/+1
| | | | | | | The new option -pass-remarks-output broke LLVM_LINK_LLVM_DYLIB because of the duplicate option name with opt. llvm-svn: 287627
* Fix test from r287353: don't use /dev/nullHans Wennborg2016-11-181-1/+1
| | | | llvm-svn: 287360
* [LTO] Add option to generate optimization recordsAdam Nemet2016-11-181-0/+17
| | | | | | | | | | It is used to drive this from the clang driver via -mllvm. Same option name is used as in opt. Differential Revision: https://reviews.llvm.org/D26832 llvm-svn: 287356
* IRMover: Avoid accidentally mapping types from the destination module (PR30799)Hans Wennborg2016-11-182-0/+70
| | | | | | | | | | | | | | During Module linking, it's possible for SrcM->getIdentifiedStructTypes(); to return types that are actually defined in the destination module (DstM). Depending on how the bitcode file was read, getIdentifiedStructTypes() might do a walk over all values, including metadata nodes, looking for types. In my case, a debug info metadata node was shared between the two modules, and it referred to a type defined in the destination module (see test case). Differential Revision: https://reviews.llvm.org/D26212 llvm-svn: 287353
* Restore "[ThinLTO] Prevent exporting of locals used/defined in module level asm"Teresa Johnson2016-11-141-0/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This restores the rest of r286297 (part was restored in r286475). Specifically, it restores the part requiring adding a dependency from the Analysis to Object library (downstream use changed to correctly model split BitReader vs BitWriter libraries). Original description of this part of patch follows: Module level asm may also contain defs of values. We need to prevent export of any refs to local values defined in module level asm (e.g. a ref in normal IR), since that also requires renaming/promotion of the local. To do that, the summary index builder looks at all values in the module level asm string that are not marked Weak or Global, which is exactly the set of locals that are defined. A summary is created for each of these local defs and flagged as NoRename. This required adding handling to the BitcodeWriter to look at GV declarations to see if they have a summary (rather than skipping them all). Finally, added an assert to IRObjectFile::CollectAsmUndefinedRefs to ensure that an MCAsmParser is available, otherwise the module asm parse would silently fail. Initialized the asm parser in the opt tool for use in testing this fix. Fixes PR30610. llvm-svn: 286844
* Revert "[ThinLTO] Prevent exporting of locals used/defined in module level asm"Mehdi Amini2016-11-091-3/+0
| | | | | | | | This reverts commit r286297. Introduces a dependency from libAnalysis to libObject, which I missed during the review. llvm-svn: 286329
* [ThinLTO] Prevent exporting of locals used/defined in module level asmTeresa Johnson2016-11-081-0/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: This patch uses the same approach added for inline asm in r285513 to similarly prevent promotion/renaming of locals used or defined in module level asm. All static global values defined in normal IR and used in module level asm should be included on either the llvm.used or llvm.compiler.used global. The former were already being flagged as NoRename in the summary, and I've simply added llvm.compiler.used values to this handling. Module level asm may also contain defs of values. We need to prevent export of any refs to local values defined in module level asm (e.g. a ref in normal IR), since that also requires renaming/promotion of the local. To do that, the summary index builder looks at all values in the module level asm string that are not marked Weak or Global, which is exactly the set of locals that are defined. A summary is created for each of these local defs and flagged as NoRename. This required adding handling to the BitcodeWriter to look at GV declarations to see if they have a summary (rather than skipping them all). Finally, added an assert to IRObjectFile::CollectAsmUndefinedRefs to ensure that an MCAsmParser is available, otherwise the module asm parse would silently fail. Initialized the asm parser in the opt tool for use in testing this fix. Fixes PR30610. Reviewers: mehdi_amini Subscribers: johanengelen, krasin, llvm-commits Differential Revision: https://reviews.llvm.org/D26146 llvm-svn: 286297
* LTO: Use the correct mangler function in ↵Peter Collingbourne2016-10-121-0/+10
| | | | | | | | | | | | LTOCodeGenerator::applyScopeRestrictions(). We need to use the overload of Mangler::getNameWithPrefix that takes a GlobalValue in order to mangle in the stdcall stack byte count for Windows targets. Differential Revision: https://reviews.llvm.org/D25529 llvm-svn: 284040
* Fix auto-upgrade of TBAA tags in Bitcode ReaderMehdi Amini2016-09-142-0/+31
| | | | | | | | | | | | | | | | | | If TBAA is on an intrinsic and it gets upgraded, it'll delete the call instruction that we collected in a vector. Even if we were to use WeakVH, it'll drop the TBAA and we'll hit the assert on the upgrade path. r263673 gave a shot to make sure the TBAA upgrade happens before intrinsics upgrade, but failed to account for all cases. Instead of collecting instructions in a vector, this patch makes it just upgrade the TBAA on the fly, because metadata are always already loaded at this point. Differential Revision: https://reviews.llvm.org/D24533 llvm-svn: 281549
* Add a libLTO API to query a memory buffer and check if it contains ObjC ↵Mehdi Amini2016-07-112-0/+111
| | | | | | | | | | | categories The linker supports a feature to force load an object from a static archive if it defines an Objective-C category. This API supports this feature by looking at every section in the module to find if a category is defined in the module. llvm-svn: 275125
* Add writeonly IR attributeNicolai Haehnle2016-07-042-1/+1
| | | | | | | | | | | | | | | | | Summary: This complements the earlier addition of IntrWriteMem and IntrWriteArgMem LLVM intrinsic properties, see D18291. Also start using the attribute for memset, memcpy, and memmove intrinsics, and remove their special-casing in BasicAliasAnalysis. Reviewers: reames, joker.eph Subscribers: joker.eph, llvm-commits Differential Revision: http://reviews.llvm.org/D18714 llvm-svn: 274485
* Remangle intrinsics names when types are renamedArtur Pilipenko2016-06-242-0/+31
| | | | | | | | | | | | | This is a resubmittion of previously reverted rL273568. This is a fix for the problem mentioned in "LTO and intrinsics mangling" llvm-dev mail thread: http://lists.llvm.org/pipermail/llvm-dev/2016-April/098387.html Reviewers: mehdi_amini, reames Differential Revision: http://reviews.llvm.org/D19373 llvm-svn: 273686
* Revert r273568 "Remangle intrinsics names when types are renamed"Hans Wennborg2016-06-232-28/+0
| | | | | | It broke 2008-07-15-Bswap.ll and 2009-09-01-PostRAProlog.ll llvm-svn: 273574
* Remangle intrinsics names when types are renamedArtur Pilipenko2016-06-232-0/+28
| | | | | | | | | | | This is a fix for the problem mentioned in "LTO and intrinsics mangling" llvm-dev mail thread: http://lists.llvm.org/pipermail/llvm-dev/2016-April/098387.html Reviewers: mehdi_amini, reames Differential Revision: http://reviews.llvm.org/D19373 llvm-svn: 273568
* IR: Introduce local_unnamed_addr attribute.Peter Collingbourne2016-06-142-35/+28
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Allow the LTO code generator to strip invalid debug info from the input.Adrian Prantl2016-05-092-0/+21
| | | | | | | | | | | | | | | | | | | | | This patch introduces a new option -lto-strip-invalid-debug-info, which drops malformed debug info from the input. The problem I'm trying to solve with this sequence of patches is that historically we've done a really bad job at verifying debug info. We want to be able to make the verifier stricter without having to worry about breaking bitcode compatibility with existing producers. For example, we don't necessarily want IR produced by an older version of clang to be rejected by an LTO link just because of malformed debug info, and rather provide an option to strip it. Note that merely outdated (but well-formed) debug info would continue to be auto-upgraded in this scenario. rdar://problem/25818489 http://reviews.llvm.org/D19987 This reapplies 268936 with a test case fix for Linux (-exported-symbol foo) llvm-svn: 268965
* Revert "Allow the LTO code generator to strip invalid debug info from the ↵Adrian Prantl2016-05-092-20/+0
| | | | | | | | input." This reverts commit 268936 while investigating buildbot breakage. llvm-svn: 268940
* Allow the LTO code generator to strip invalid debug info from the input.Adrian Prantl2016-05-092-0/+20
| | | | | | | | | | | | | | | | | | | This patch introduces a new option -lto-strip-invalid-debug-info, which drops malformed debug info from the input. The problem I'm trying to solve with this sequence of patches is that historically we've done a really bad job at verifying debug info. We want to be able to make the verifier stricter without having to worry about breaking bitcode compatibility with existing producers. For example, we don't necessarily want IR produced by an older version of clang to be rejected by an LTO link just because of malformed debug info, and rather provide an option to strip it. Note that merely outdated (but well-formed) debug info would continue to be auto-upgraded in this scenario. rdar://problem/25818489 http://reviews.llvm.org/D19987 llvm-svn: 268936
* LTO: Don't bother trying to mangle unnamed globals, as they can't be ↵Peter Collingbourne2016-04-271-0/+10
| | | | | | | | | | | | | | preserved with MustPreserveSymbols. Summary: Should fix sanitizer-windows bot. Reviewers: joker.eph Subscribers: llvm-commits, joker.eph Differential Revision: http://reviews.llvm.org/D19635 llvm-svn: 267820
* Revert "Support "preserving" the summary information when using setModule() ↵Mehdi Amini2016-04-271-37/+0
| | | | | | | | | | API in LTOCodeGenerator" This reverts commit r267665. ASAN shows that there is a use of undefined value. From: Mehdi Amini <mehdi.amini@apple.com> llvm-svn: 267668
* Support "preserving" the summary information when using setModule() API in ↵Mehdi Amini2016-04-271-0/+37
| | | | | | | | | LTOCodeGenerator Another attempt at r267655... From: Mehdi Amini <mehdi.amini@apple.com> llvm-svn: 267665
* Revert "Support "preserving" the summary information when using setModule() ↵Mehdi Amini2016-04-271-37/+0
| | | | | | | | | | API in LTOCodeGenerator" This reverts commit r267657, r267656, and r267655. The test does not pass on multiple bots, I'm unsure why yet but let's unbreak them. From: Mehdi Amini <mehdi.amini@apple.com> llvm-svn: 267664
* Fix the test from r267656: Support "preserving" the summary information when ↵Mehdi Amini2016-04-271-2/+0
| | | | | | | using setModule() API in LTOCodeGenerator From: Mehdi Amini <mehdi.amini@apple.com> llvm-svn: 267657
* Add a test for r267655: Support "preserving" the summary information when ↵Mehdi Amini2016-04-271-0/+39
| | | | | | | using setModule() API in LTOCodeGenerator From: Mehdi Amini <mehdi.amini@apple.com> llvm-svn: 267656
* Refactor the InternalizePass into a helper class, and expose it through a ↵Mehdi Amini2016-04-131-2/+1
| | | | | | | | | | public free function (NFC) There is really no reason to require to instanciate a pass manager to internalize. From: Mehdi Amini <mehdi.amini@apple.com> llvm-svn: 266167
* Refactor the Internalize stage of libLTO in a separate file (NFC)Mehdi Amini2016-04-121-2/+2
| | | | | | | | | | | | | | | | | This is intended to be shared by the ThinLTOCodeGenerator. Note that there is a change in the way the verifier is run, previously it was ran as a Pass on the merged module during internalization. While now the verifier is called explicitely on the merged module outside of the internalize "pass pipeline". What remains strange in the API is the fact that `DisableVerify` in the API does not disable this initial verifier. Differential Revision: http://reviews.llvm.org/D19000 From: Mehdi Amini <mehdi.amini@apple.com> llvm-svn: 266047
* Revert r265817Colin LeMahieu2016-04-081-1/+1
| | | | | | lld tests need to be addressed. llvm-svn: 265822
* [LoopVectorize] Don't unconditionally print vectorization diagnosticsAkira Hatanaka2016-04-011-2/+50
| | | | | | | | | | | | | | | | | when compiling with LTO. r244523 a new class DiagnosticInfoOptimizationRemarkAnalysisAliasing for optimization analysis remarks related to pointer aliasing without guarding it in isDiagnosticEnabled in LLVMContext.cpp. This caused the diagnostic message to be printed unconditionally when compiling with LTO. This commit cleans up isDiagnosticEnabled and makes sure all the vectorization optimization remarks are guarded. rdar://problem/25382153 llvm-svn: 265084
* Rename embedded bitcode section in MachOSteven Wu2016-02-291-1/+4
| | | | | | | | | | | | | | Summary: Rename the section embeds bitcode from ".llvmbc,.llvmbc" to "__LLVM,__bitcode". The new name matches MachO section naming convention. Reviewers: rafael, pcc Subscribers: davide, llvm-commits, joker.eph Differential Revision: http://reviews.llvm.org/D17388 llvm-svn: 262245
* [LTO] Restore original linkage of externals prior to splittingTobias Edler von Koch2016-01-181-0/+24
| | | | | | | | | | | | | | | | | | | | | | | Summary: This is a companion patch for http://reviews.llvm.org/D16124. Internalized symbols increase the size of strongly-connected components in SCC-based module splitting and thus reduce the amount of parallelism. This patch records the original linkage of non-local symbols prior to internalization and then restores it just before splitting/CodeGen. This is also useful for cases where the linker requires symbols to remain external, for instance, so they can be placed according to linker script rules. It's currently under its own flag (-restore-globals) but should eventually share a common flag with D16124. Reviewers: joker.eph, pcc Subscribers: slarin, llvm-commits, joker.eph Differential Revision: http://reviews.llvm.org/D16229 llvm-svn: 258100
* Don't try to check all uses if lazy loading.Rafael Espindola2016-01-151-0/+11
| | | | | | | | | | | This means that LTO_SYMBOL_SCOPE_DEFAULT_CAN_BE_HIDDEN will not be set in a few cases. This should have no impact in ld64 since it doesn't use lazy loading when merging modules and that is when it checks LTO_SYMBOL_SCOPE_DEFAULT_CAN_BE_HIDDEN. llvm-svn: 257915
* Add InaccessibleMemOnly and inaccessibleMemOrArgMemOnly attributesVaivaswatha Nagaraj2015-12-162-1/+1
| | | | | | | | | | | | | | | | | | Summary: This patch introduces two new function attributes InaccessibleMemOnly: This attribute indicates that the function may only access memory that is not accessible by the program/IR being compiled. This is a weaker form of ReadNone. inaccessibleMemOrArgMemOnly: This attribute indicates that the function may only access memory that is either not accessible by the program/IR being compiled, or is pointed to by its pointer arguments. This is a weaker form of ArgMemOnly Test cases have been updated. This revision uses this (https://github.com/llvm-mirror/llvm/commit/d001932f3a8aa1ebd1555162fdce365f011bc292) as reference. Reviewers: jmolloy, hfinkel Subscribers: reames, joker.eph, llvm-commits Differential Revision: http://reviews.llvm.org/D15499 llvm-svn: 255778
* [LTO] Add options to llvm-lto to select output format and dump merged moduleTobias Edler von Koch2015-11-201-0/+21
| | | | | | | | | | | | This introduces two new options: - "llvm-lto -save-merged-module -o outfile" dumps the LTO Module to outfile.merged.bc prior to CodeGen and after LTO optimizations have been run. - "llvm-lto -filetype=asm -o outfile" makes llvm-lto emit assembly instead of object code in outfile. Both are intended for use in lit tests. llvm-svn: 253624
* [LTO] Add an early run of functionattrsJames Molloy2015-11-181-1/+4
| | | | | | Because we internalize early, we can potentially mark a bunch of functions as norecurse. Do this before globalopt. llvm-svn: 253451
OpenPOWER on IntegriCloud