summaryrefslogtreecommitdiffstats
path: root/llvm/test/ThinLTO/X86
Commit message (Collapse)AuthorAgeFilesLines
...
* Revert "[IR] Remove the DIExpression field from DIGlobalVariable."Adrian Prantl2016-12-163-3/+3
| | | | | | This reverts commit 289902 while investigating bot berakage. llvm-svn: 289906
* [IR] Remove the DIExpression field from DIGlobalVariable.Adrian Prantl2016-12-163-3/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | 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
* [ThinLTO] Thin link efficiency improvement: don't re-export globals (NFC)Teresa Johnson2016-12-152-0/+36
| | | | | | | | | | | | | | | | | Summary: We were reinvoking exportGlobalInModule numerous times redundantly. No need to re-export globals referenced by a global that was already imported from its module. This resulted in a large speedup in the thin link for a big application, particularly when importing aggressiveness was cranked up. Reviewers: mehdi_amini Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D27687 llvm-svn: 289896
* [LTO] Reject modules without datalayout.Davide Italiano2016-12-142-0/+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
* [ThinLTO] Add an API to trigger file-based API for returning objects to the ↵Mehdi Amini2016-12-141-0/+30
| | | | | | | | | | | | | | | | | | | | linker Summary: The motivation is to support better the -object_path_lto option on Darwin. The linker needs to write down the generate object files on disk for later use by lldb or dsymutil (debug info are not present in the final binary). We're moving this into libLTO so that we can be smarter when a cache is enabled and hard-link when possible instead of duplicating the files. Reviewers: tejohnson, deadalnix, pcc Subscribers: dexonsmith, llvm-commits Differential Revision: https://reviews.llvm.org/D27507 llvm-svn: 289631
* [ThinLTO] Import only necessary DICompileUnit fieldsTeresa Johnson2016-12-122-0/+93
| | | | | | | | | | | | | | | | | | | | | | | | | Summary: As discussed on mailing list, for ThinLTO importing we don't need to import all the fields of the DICompileUnit. Don't import enums, macros, retained types lists. Also only import local scoped imported entities. Since we don't currently import any global variables, we also don't need to import the list of global variables (added an assert to verify none are being imported). This is being done by pre-populating the value map entries to map the unneeded metadata to nullptr. For the imported entities, we can simply replace the source module's list with a new list containing only those needed imported entities. This is done in the IRLinker constructor so that value mapping automatically does the desired mapping. Reviewers: mehdi_amini, dexonsmith, dblaikie, aprantl Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D27635 llvm-svn: 289441
* LTO: Hash the parts of the LTO configuration that affect code generation.Peter Collingbourne2016-12-081-0/+27
| | | | | | | | | Most importantly, we need to hash the relocation model, otherwise we can end up trying to link non-PIC object files into PIEs or DSOs. Differential Revision: https://reviews.llvm.org/D27556 llvm-svn: 289024
* [LTOs] Allow generation of hotness informationAdam Nemet2016-12-021-0/+56
| | | | | | | | 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-17/+17
| | | | | | This ensures that we don't generate the hotness attribute by default. llvm-svn: 288518
* [ThinLTO] Stop importing constant global vars as copies in the backendTeresa Johnson2016-12-025-6/+60
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: We were doing an optimization in the ThinLTO backends of importing constant unnamed_addr globals unconditionally as a local copy (regardless of whether the thin link decided to import them). This should be done in the thin link instead, so that resulting exported references are marked and promoted appropriately, but will need a summary enhancement to mark these variables as constant unnamed_addr. The function import logic during the thin link was trying to handle this proactively, by conservatively marking all values referenced in the initializer lists of exported global variables as also exported. However, this only handled values referenced directly from the initializer list of an exported global variable. If the value is itself a constant unnamed_addr variable, we could end up exporting its references as well. This caused multiple issues. The first is that the transitively exported references weren't promoted. Secondly, some could not be promoted/renamed (e.g. they had a section or other constraint). recursively, instead of just adding the first level of initializer list references to the ExportList directly. Remove this optimization and the associated handling in the function import backend. SPEC measurements indicate we weren't getting much from it in any case. Fixes PR31052. Reviewers: mehdi_amini Subscribers: krasin, llvm-commits Differential Revision: https://reviews.llvm.org/D26880 llvm-svn: 288446
* llvm-lto2: Simpler workaround for PR30396.Peter Collingbourne2016-11-301-0/+1
| | | | | | | | | | | Maintain the command line resolutions as a map to a list of resolutions rather than a single resolution, and apply the resolutions in the order observed. This is not only simpler but allows us to test the scenario where the two symbols have different resolutions. Differential Revision: https://reviews.llvm.org/D27285 llvm-svn: 288288
* 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
* [ThinLTO] Fix crash when importing an opaque typeMehdi Amini2016-11-192-0/+42
| | | | | | | | | | | | | | | | | | | | | | | | | | It seems that because ThinLTO does not import the full module, some invariant of the type mapper are broken. In Monolithic LTO, we import every globals: when calling IRLinker::copyFunctionProto() on @foo(), we end-up calling TypeMapTy::get(FTy) on the type of @foo(), which will map %0 and record the destination as opaque. ThinLTO skips this because @foo is not imported and goes directly to the next stage. Next we call computeTypeMapping() that map the types for each globals, and ends up checking for type isomorphism, and may add type mapping. However it doesn't record if there was an opaque destination type that was resolved. Instead of lazily "discovering" opaque type in the destination module on the go, we change the TypeFinder to eagerly record all types and not only the named ones. Differential Revision: https://reviews.llvm.org/D26840 llvm-svn: 287453
* [ThinLTO] Implement -pass-remarks-output in ThinLTOCodeGeneratorMehdi Amini2016-11-192-0/+61
| | | | | | | | | | | | | | Summary: This will also be added to the LTO API, right now this will bring ThinLTO on par with Monolithic LTO on Darwin. Reviewers: anemet Subscribers: tejohnson, llvm-commits Differential Revision: https://reviews.llvm.org/D26886 llvm-svn: 287450
* [ThinLTO] Only promote exported locals as marked in indexTeresa Johnson2016-11-141-12/+12
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: We have always speculatively promoted all renamable local values (except const non-address taken variables) for both the exporting and importing module. We would then internalize them back based on the ThinLink results if they weren't actually exported. This is inefficient, and results in unnecessary renames. It also meant we had to check the non-renamability of a value in the summary, which was already checked during function importing analysis in the ThinLink. Made renameModuleForThinLTO (which does the promotion/renaming) instead use the index when exporting, to avoid unnecessary renames/promotions. For importing modules, we can simply promoted all values as any local we import by definition is exported and needs promotion. This required changes to the method used by the FunctionImport pass (only invoked from 'opt' for testing) and when invoked from llvm-link, since neither does a ThinLink. We simply conservatively mark all locals in the index as promoted, which preserves the current aggressive promotion behavior. I also needed to change an llvm-lto based test where we had previously been aggressively promoting values that weren't importable (aliasees), but now will not promote. Reviewers: mehdi_amini Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D26467 llvm-svn: 286871
* Restore "[ThinLTO] Prevent exporting of locals used/defined in module level asm"Teresa Johnson2016-11-141-5/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Restore part of "[ThinLTO] Prevent exporting of locals used/defined in ↵Teresa Johnson2016-11-102-0/+99
| | | | | | | | | | | | | | | | | module level asm" This restores the part of r286297 that didn't require adding a dependency from the Analysis to Object library. There are two parts to the original fix, and this will address the handling for the case where locals are used in module level asm. The part that requires functionality in libObject handles local defs in module level asm, and was reverted because our downstream build of clang builds lib/Bitcode into a single library, and this new dependency introduced a cycle there. I am trying to get that fixed (see D26502), so for now that change isn't being restored llvm-svn: 286475
* Revert "[ThinLTO] Prevent exporting of locals used/defined in module level asm"Mehdi Amini2016-11-092-96/+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-082-0/+96
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* [ThinLTO] Handle distributed backend case when doing renamingTeresa Johnson2016-11-032-0/+26
| | | | | | | | | | | | | | | | | | | | | | | Summary: The recent change I made to consult the summary when deciding whether to rename (to handle inline asm) in r285513 broke the distributed build case. In a distributed backend we will only have a portion of the combined index, specifically for imported modules we only have the summaries for any imported definitions. When renaming on import we were asserting because no summary entry was found for a local reference being linked in (def wasn't imported). We only need to consult the summary for a renaming decision for the exporting module. For imports, we would have prevented importing any references to NoRename values already. Reviewers: mehdi_amini Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D26250 llvm-svn: 285871
* [ThinLTO] Disable importing and other cross-module optis at -O0Teresa Johnson2016-10-312-0/+39
| | | | | | | | | | | | | | | | Summary: There is no point to importing at -O0, since we won't inline. We should also disable other cross-module optimizations. (Plan to backport this fix to the 3.9 branch to fix PR30774) Reviewers: pcc Subscribers: johanengelen, mehdi_amini Differential Revision: https://reviews.llvm.org/D25918 llvm-svn: 285648
* [ThinLTO] Correctly resolve linkonce when importing aliaseeTeresa Johnson2016-10-304-6/+70
| | | | | | | | | | | | | | | | | | | Summary: When we have an aliasee that is linkonce, while we can't convert the non-prevailing copies to available_externally, we still need to convert the prevailing copy to weak. If a reference to the aliasee is exported, not converting a copy to weak will result in undefined references when the linkonce is removed in its original module. Add a new test and update existing tests. Reviewers: mehdi_amini Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D26076 llvm-svn: 285512
* [ThinLTO] Don't link module level assembly when importingTeresa Johnson2016-10-122-0/+43
| | | | | | | | | | | | | | | | | | | | | Module inline asm was always being linked/concatenated when running the IRLinker. This is correct for full LTO but not when we are importing for ThinLTO, as it can result in multiply defined symbols when the module asm defines a global symbol. In order to test with llvm-lto2, I had to work around PR30396, where a symbol that is defined in module assembly but defined in the LLVM IR appears twice. Added workaround to llvm-lto2 with a FIXME. Fixes PR30610. Reviewers: mehdi_amini Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D25359 llvm-svn: 284030
* ThinLTO: don't perform incremental LTO on module without a hashMehdi Amini2016-10-082-2/+24
| | | | | | | | | Clang always emit a hash for ThinLTO, but as other frontend are starting to use ThinLTO, this could be a serious bug. Differential Revision: https://reviews.llvm.org/D25379 llvm-svn: 283655
* ThinLTO: handles modules with empty summariesMehdi Amini2016-10-082-0/+43
| | | | | | | | | | | | | We need to add an entry in the combined-index for modules that have a hash but otherwise empty summary, this is needed so that we can get the hash for the module. Also, if no entry is present in the combined index for a module, we need to skip it when trying to compute a cache entry. Differential Revision: https://reviews.llvm.org/D25300 llvm-svn: 283654
* [ThinLTO] Always emit a summary when compiling in ThinLTO modeTeresa Johnson2016-09-203-3/+25
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: Emit an empty summary section, instead of no summary section, when there are no global variables in the index. This ensures that LTO will treat these files as ThinLTO inputs, instead of as regular LTO inputs. In addition to not being what the user likely intended when compiling with -flto=thin, the current behavior is problematic for distributed build systems that expect to get ThinLTO index and imports files back for each input compiled with -flto=thin. Combining into a single regular LTO module also reduces the backend parallelism. And in the case where the index was suppressed due to uses in inline assembly, combining into a single LTO module could provoke renaming of duplicates that we were trying to prevent by suppressing the index. This change required a couple of fixes to handle the empty summary section. Reviewers: mehdi_amini Subscribers: mehdi_amini, llvm-commits, pcc Differential Revision: https://reviews.llvm.org/D24779 llvm-svn: 282037
* [ThinLTO] Add an option to llvm-lto to print some basic statistics for the indexMehdi Amini2016-09-141-0/+3
| | | | | | Differential Revision: https://reviews.llvm.org/D24290 llvm-svn: 281537
* DebugInfo: New metadata representation for global variables.Peter Collingbourne2016-09-133-4/+4
| | | | | | | | | | | | | This patch reverses the edge from DIGlobalVariable to GlobalVariable. This will allow us to more easily preserve debug info metadata when manipulating global variables. Fixes PR30362. A program for upgrading test cases is attached to that bug. Differential Revision: http://reviews.llvm.org/D20147 llvm-svn: 281284
* Fix ThinLTO crash with debug infoMehdi Amini2016-09-032-0/+79
| | | | | | | | | | | | Because the recent change about ODR type uniquing in the context, we can reach types defined in another module during IR linking. This triggered some assertions in case we IR link without starting from an empty module. To alleviate that, we can self-map metadata defined in the destination module so that they won't be visited. Differential Revision: https://reviews.llvm.org/D23841 llvm-svn: 280599
* [ThinLTO] Add caching to the new LTO APIMehdi Amini2016-08-231-1/+9
| | | | | | | | | | | | Add the ability to plug a cache on the LTO API. I tried to write such that a linker implementation can control the cache backend. This is intrusive and I'm not totally happy with it, but I can't figure out a better design right now. Differential Revision: https://reviews.llvm.org/D23599 llvm-svn: 279576
* [LTO] Fix test following r279550Mehdi Amini2016-08-231-1/+1
| | | | | | | The output name changed, but it was passing locally using the old output still present in the build dir. llvm-svn: 279556
* [ThinLTO] Add a llvm-lto2 test to check that ODR type uniquing is enabled (NFC)Mehdi Amini2016-08-232-0/+45
| | | | | | | | This adds a test for r279532, thanks David Li for noticing :) Recommit r279545 after committing first a dependent patch. llvm-svn: 279551
* Revert "[ThinLTO] Add a llvm-lto2 test to check that ODR type uniquing is ↵Mehdi Amini2016-08-232-45/+0
| | | | | | | | enabled (NFC)" This reverts commit r279545, test is failing, my Output dir was dirty and making the test pass. llvm-svn: 279549
* [ThinLTO] Add a llvm-lto2 test to check that ODR type uniquing is enabled (NFC)Mehdi Amini2016-08-232-0/+45
| | | | | | This adds a test for r279532, thanks David Li for noticing :) llvm-svn: 279545
* [ThinLTO][X86] Fix windows buildSimon Pilgrim2016-08-221-1/+2
| | | | | | Windows 'rm' complains about non-existent files if a wildcard is used. Be more explicit about the files deleted to avoid this. llvm-svn: 279426
* [LTO] Add the ability to test -thinlto-emit-imports-files through llvm-lto2Mehdi Amini2016-08-191-0/+13
| | | | | | | | | | | | | | Summary: Start bringing llvm-lto2 to a level where we can test the LTO API a bit deeper. Reviewers: tejohnson Subscribers: llvm-commits, mehdi_amini Differential Revision: https://reviews.llvm.org/D23681 llvm-svn: 279349
* [LTO] Promote before performing weak resolutionMehdi Amini2016-08-181-0/+13
| | | | | | | | | | | | | | | | Summary: This was reversed compared to ThinLTOCodeGenerator for some reason, and lead to an increased code-size on my tests. I figured that the weak resolution may internalize a linkonce function, which will be promoted immediately (and renamed), before being internalized again. Reviewers: tejohnson Subscribers: pcc, llvm-commits, mehdi_amini Differential Revision: https://reviews.llvm.org/D23632 llvm-svn: 279021
* [ThinLTO] Fix temp file dumping, enable via llvm-lto and test itTeresa Johnson2016-08-151-1/+9
| | | | | | | | | | | | | | | | | | | Summary: Fixed a bug in ThinLTOCodeGenerator's temp file dumping. The Twine needs to be passed directly as an argument, or a copy saved into a std::string. It doesn't seem there are any consumers of this, so I added a new option to llvm-lto to enable saving of temp files during ThinLTO, and augmented a test to use it to check post-import but pre-opt bitcode. Reviewers: mehdi_amini Subscribers: llvm-commits, mehdi_amini Differential Revision: https://reviews.llvm.org/D23525 llvm-svn: 278761
* Remove unnecessary flag from new testTeresa Johnson2016-08-151-1/+1
| | | | | | | | Remove -disable-inlining flag that snuck into the test I added for r278739. It doesn't have an effect in ThinLTO mode (something that should be fixed), but in any case the checks depend on inlining currently. llvm-svn: 278743
* [ThinLTO] Remove functions resolved to available_externally from comdatsTeresa Johnson2016-08-152-0/+36
| | | | | | | | | | | | | | | | Summary: thinLTOResolveWeakForLinkerModule needs to drop any preempted weak symbols that were converted to available_externally from comdats, otherwise we will get a verification failure (since available_externally is a declaration for the linker, and no declarations can be in a comdat). Reviewers: mehdi_amini Subscribers: llvm-commits, mehdi_amini Differential Revision: https://reviews.llvm.org/D23015 llvm-svn: 278739
* Fix bitcode auto-upgrade when using bitcode lazy loadingMehdi Amini2016-08-142-0/+23
| | | | | | | | | | | | The auto-upgrade path could be called before the VST (global names) was fully parsed, and thus intrinsic names were not available and the autoupgrade logic could not operate. Fix link failures with ThinLTO. This is a recommit of r278610 with a different fix. llvm-svn: 278615
* Revert "Fix bitcode auto-upgrade when using bitcode lazy loading"Mehdi Amini2016-08-132-23/+0
| | | | | | This reverts commit r278610. Tests are broken llvm-svn: 278613
* Fix bitcode auto-upgrade when using bitcode lazy loadingMehdi Amini2016-08-132-0/+23
| | | | | | | | | | The auto-upgrade path could be called before the VST (global names) was fully parsed, and thus intrinsic names were not available and the autoupgrade logic could not operate. Fix link failures with ThinLTO. llvm-svn: 278610
* ThinLTO: Do not take into account whether a definition has multiple copies ↵Peter Collingbourne2016-07-072-12/+12
| | | | | | | | | | | | | | | | | | | | | | when promoting. We currently do not touch a symbol's linkage in the case where a definition has a single copy. However, this code is effectively unnecessary: either the definition is not exported, in which case the internalize phase sets its linkage to internal, or it is exported, in which case we need to promote linkage to weak. Those two cases are already handled by existing code. I believe that the only real functional change here is in the case where we have a single definition which does not prevail (e.g. because the definition in a native object file prevails). In that case we now lower linkage to available_externally following the existing code path for that case. As a result we can remove the isExported function parameter from the thinLTOResolveWeakForLinkerInIndex function. Differential Revision: http://reviews.llvm.org/D21883 llvm-svn: 274784
* ThinLTO: Remove check for multiple modules before applying weak resolutions.Peter Collingbourne2016-07-071-0/+9
| | | | | | | | | | This check is not only unnecessary, it can produce the wrong result. If we are linking a single module and it has an exported linkonce symbol, we need to promote to weak in order to avoid PR19901-style problems. Differential Revision: http://reviews.llvm.org/D21917 llvm-svn: 274722
* ThinLTO: Add test cases for promote+internalize.Peter Collingbourne2016-07-062-1/+43
| | | | | | | | | This tests the effect of both promotion and internalization on a module, and helps show that D21883 is NFC wrt promotion+internalization. Differential Revision: http://reviews.llvm.org/D21915 llvm-svn: 274699
* [ThinLTO] Resolve LinkOnceAnyTeresa Johnson2016-05-263-11/+39
| | | | | | | | | | | | | | | | | Summary: Ensure we keep prevailing copy of LinkOnceAny by converting it to WeakAny. Rename odr_resolution test to the now more appropriate weak_resolution (weak in the linker sense includes linkonce). Reviewers: joker.eph Subscribers: llvm-commits, joker.eph Differential Revision: http://reviews.llvm.org/D20634 llvm-svn: 270850
* [ThinLTO] Fix test check prefix so that intended prefix testedTeresa Johnson2016-05-251-1/+1
| | | | | | | There aren't any checks with prefix PROMOTE, should be PROMOTE_MOD1 which wasn't being tested (but works as expected). llvm-svn: 270719
* [ThinLTO] Use semicolon to separate path prefix replacementReid Kleckner2016-05-171-2/+1
| | | | | | | | | | | | | | | | Summary: Colons can appear in Windows paths after drive letters. Both colon and semicolon are valid characters in filenames, but neither are very common. Semicolon seems just as good, and makes the test pass on Windows. Reviewers: tejohnson Subscribers: joker.eph, llvm-commits Differential Revision: http://reviews.llvm.org/D20332 llvm-svn: 269798
* [ThinLTO] Force disable test on Windows via REQUIRES shellTeresa Johnson2016-05-171-1/+1
| | | | | | | | | | The "XFAIL: win32" was not enough to get the test to XFAIL on the bot: http://lab.llvm.org:8011/builders/llvm-clang-lld-x86_64-scei-ps4-windows10pro-fast/builds/5478 For now, use "REQUIRES: shell" to suppress test on Windows while we investigate. llvm-svn: 269777
OpenPOWER on IntegriCloud