summaryrefslogtreecommitdiffstats
path: root/llvm/test/LTO
Commit message (Collapse)AuthorAgeFilesLines
...
* [LTO] Fix handling of mixed (regular and thin) mode LTOTeresa Johnson2016-09-162-0/+25
| | | | | | | | | | | | | | | | | | | | | Summary: In runThinLTO we start the task numbering for ThinLTO backend tasks depending on whether there was also a regular LTO object (CombinedModule). However, the CombinedModule is moved at the end of runRegularLTO, so we need to save this information and pass it into runThinLTO. Otherwise the AddOutput callback to the client will use the same task number for both the regular LTO object and the first ThinLTO object, which in gold-plugin caused only one to be end up in the output filename array and therefore passed back to gold for the final native link. Reviewers: pcc, mehdi_amini Subscribers: mehdi_amini, kromanova Differential Revision: https://reviews.llvm.org/D24643 llvm-svn: 281725
* 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
* [LTO] Move tests from test/tools to test/LTO, as they're testing the API ↵Mehdi Amini2016-09-142-0/+96
| | | | | | functionalities (NFC) llvm-svn: 281539
* [LTO] Fix commons handlingMehdi Amini2016-09-142-0/+16
| | | | | | | | | | | | | | Previously the prevailing information was not honored, and commons symbols could override a strong definition. This patch fixes it and propose the following semantic for commons: the client should mark as prevailing the commons that it expects the LTO implementation to merge (i.e. take the maximum size and alignment). It implies that commons are allowed to have multiple prevailing definitions. Differential Revision: https://reviews.llvm.org/D24545 llvm-svn: 281538
* [LTO] Change addSaveTemps API: do not add dot to the supplied prefix pathMehdi Amini2016-08-182-2/+2
| | | | | | | | | | | | | | | | Summary: It does not play well with directories (end up with a bunch of hidden files). Also, do not strip the 0 suffix for the first task, especially since 0 can be used by ThinLTO as well now. Reviewers: tejohnson Subscribers: mehdi_amini, pcc, llvm-commits Differential Revision: https://reviews.llvm.org/D23612 llvm-svn: 279014
* Restore "Resolution-based LTO API."Teresa Johnson2016-08-115-0/+142
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This restores commit r278330, with fixes for a few bot failures: - Fix a late change I had made to the save temps output file that I missed due to existing files sitting on my disk - Fix a bunch of Windows bot failures with "ambiguous call to overloaded function" due to confusion between llvm::make_unique vs std::make_unique (preface the new make_unique calls with "llvm::") - Attempt to fix a modules bot failure by adding a missing include to LTO/Config.h. Original change: Resolution-based LTO API. Summary: This introduces a resolution-based LTO API. The main advantage of this API over existing APIs is that it allows the linker to supply a resolution for each symbol in each object, rather than the combined object as a whole. This will become increasingly important for use cases such as ThinLTO which require us to process symbol resolutions in a more complicated way than just adjusting linkage. Patch by Peter Collingbourne. Reviewers: rafael, tejohnson, mehdi_amini Subscribers: lhames, tejohnson, mehdi_amini, llvm-commits Differential Revision: https://reviews.llvm.org/D20268 llvm-svn: 278338
* Revert "Resolution-based LTO API."Teresa Johnson2016-08-115-142/+0
| | | | | | | | | | This reverts commit r278330. I made a change to the save temps output that is causing issues with the bots. Didn't realize this because I had older output files sitting on disk in my test output directory. llvm-svn: 278331
* Resolution-based LTO API.Teresa Johnson2016-08-115-0/+142
| | | | | | | | | | | | | | | | | | | | | | Summary: This introduces a resolution-based LTO API. The main advantage of this API over existing APIs is that it allows the linker to supply a resolution for each symbol in each object, rather than the combined object as a whole. This will become increasingly important for use cases such as ThinLTO which require us to process symbol resolutions in a more complicated way than just adjusting linkage. Patch by Peter Collingbourne. Reviewers: rafael, tejohnson, mehdi_amini Subscribers: lhames, tejohnson, mehdi_amini, llvm-commits Differential Revision: https://reviews.llvm.org/D20268 Address review comments llvm-svn: 278330
* 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
* Add a libLTO diagnostic handler that supports lto_get_error_message APIYunzhong Gao2015-11-111-2/+2
| | | | | | | | | | | | | | This is a follow-up from the previous discussion on the thread: http://lists.llvm.org/pipermail/llvm-commits/Week-of-Mon-20151019/307763.html The LibLTO lto_get_error_message() API reads error messages from a std::string sLastErrorString. Instead of passing this string around as an argument, this patch creates a diagnostic handler and then sends this handler to the constructor of LTOCodeGenerator. Differential Revision: http://reviews.llvm.org/D14313 llvm-svn: 252791
* llvm-lto: trivial spelling changes to distinguish custom diagnostic handler andYunzhong Gao2015-11-101-1/+3
| | | | | | | | default diagnostic handler. Differential Revision: http://reviews.llvm.org/D14520 llvm-svn: 252633
* Add a new attribute: norecurseJames Molloy2015-11-062-1/+1
| | | | | | This attribute allows the compiler to assume that the function never recurses into itself, either directly or indirectly (transitively). This can be used among other things to demote global variables to locals. llvm-svn: 252282
* Make the default triple optional by allowing an empty stringMehdi Amini2015-09-163-0/+4
| | | | | | | | | | | | | | | When building LLVM as a (potentially dynamic) library that can be linked against by multiple compilers, the default triple is not really meaningful. We allow to explicitely set it to an empty string when configuring LLVM. In this case, said "target independent" tests in the test suite that are using the default triple are disabled by matching the newly available feature "default_triple". Reviewers: probinson, echristo Differential Revision: http://reviews.llvm.org/D12660 From: Mehdi Amini <mehdi.amini@apple.com> llvm-svn: 247775
* Reapply "LTO: Disable extra verify runs in release builds"Duncan P. N. Exon Smith2015-09-151-0/+18
| | | | | | | This reverts commit r247730, effectively reapplying r247729. This time I have an lld commit ready to follow. llvm-svn: 247735
* Revert "LTO: Disable extra verify runs in release builds"Duncan P. N. Exon Smith2015-09-151-18/+0
| | | | | | | This temporarily reverts commit r247729, as it caused lld build failures. I'll recommit once I have an lld patch ready-to-go. llvm-svn: 247730
* LTO: Disable extra verify runs in release buildsDuncan P. N. Exon Smith2015-09-151-0/+18
| | | | | | | | | | | | | | | | | | | | | | The verifier currently runs three times in LTO: (1) after parsing, (2) at the beginning of the optimization pipeline, and (3) at the end of it. The first run is important, since we're not sure where the bitcode comes from and it's nice to validate it, but in release builds the extra runs aren't appropriate. This commit: - Allows these runs to be disabled in LTOCodeGenerator. - Adds command-line options to llvm-lto. - Adds command-line options to libLTO.dylib, and disables the verifier by default in release builds (based on NDEBUG). This shaves about 3.5% off the runtime of ld64 when linking verify-uselistorder with -flto -g. rdar://22509081 llvm-svn: 247729
* Add a non-exiting diagnostic handler for LTO.Yunzhong Gao2015-09-111-0/+13
| | | | | | | This is in order to give LTO clients a chance to do some clean-up before terminating the process. llvm-svn: 247461
* Add powerpc64 to parallel.ll unsupported architecture list.Peter Collingbourne2015-09-041-1/+1
| | | | llvm-svn: 246862
* Use UNSUPPORTED instead of XFAIL to disable this test, as it passes on one ↵Peter Collingbourne2015-08-281-1/+1
| | | | | | AArch64 bot. llvm-svn: 246344
* Tweak XFAIL line for mips.Peter Collingbourne2015-08-281-1/+1
| | | | llvm-svn: 246269
* XFAIL parallel.ll test on MIPS and AArch64 until test failures can be ↵Peter Collingbourne2015-08-281-0/+3
| | | | | | investigated. llvm-svn: 246261
* CodeGen: Introduce splitCodeGen and teach LTOCodeGenerator to use it.Peter Collingbourne2015-08-271-0/+22
| | | | | | | | | | | | | | | llvm::splitCodeGen is a function that implements the core of parallel LTO code generation. It uses llvm::SplitModule to split the module into linkable partitions and spawning one code generation thread per partition. The function produces multiple object files which can be linked in the usual way. This has been threaded through to LTOCodeGenerator (and llvm-lto for testing purposes). Separate patches will add parallel LTO support to the gold plugin and lld. Differential Revision: http://reviews.llvm.org/D12260 llvm-svn: 246236
* Move the personality function from LandingPadInst to FunctionDavid Majnemer2015-06-171-2/+2
| | | | | | | | | | | | | | | | | | | The personality routine currently lives in the LandingPadInst. This isn't desirable because: - All LandingPadInsts in the same function must have the same personality routine. This means that each LandingPadInst beyond the first has an operand which produces no additional information. - There is ongoing work to introduce EH IR constructs other than LandingPadInst. Moving the personality routine off of any one particular Instruction and onto the parent function seems a lot better than have N different places a personality function can sneak onto an exceptional function. Differential Revision: http://reviews.llvm.org/D10429 llvm-svn: 239940
* Revert changes to LTO test case since llvm-lto can't handle textual IR inputsDavid Blaikie2015-04-241-1/+2
| | | | llvm-svn: 235738
* Skip extra LLVM IR assemble/disassemble steps in some testsDavid Blaikie2015-04-241-2/+1
| | | | llvm-svn: 235736
* [opaque pointer type] Add textual IR support for explicit type parameter to ↵David Blaikie2015-04-162-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | the call instruction See r230786 and r230794 for similar changes to gep and load respectively. Call is a bit different because it often doesn't have a single explicit type - usually the type is deduced from the arguments, and just the return type is explicit. In those cases there's no need to change the IR. When that's not the case, the IR usually contains the pointer type of the first operand - but since typed pointers are going away, that representation is insufficient so I'm just stripping the "pointerness" of the explicit type away. This does make the IR a bit weird - it /sort of/ reads like the type of the first operand: "call void () %x(" but %x is actually of type "void ()*" and will eventually be just of type "ptr". But this seems not too bad and I don't think it would benefit from repeating the type ("void (), void () * %x(" and then eventually "void (), ptr %x(") as has been done with gep and load. This also has a side benefit: since the explicit type is no longer a pointer, there's no ambiguity between an explicit type and a function that returns a function pointer. Previously this case needed an explicit type (eg: a function returning a void() function was written as "call void () () * @x(" rather than "call void () * @x(" because of the ambiguity between a function returning a pointer to a void() function and a function returning void). No ambiguity means even function pointer return types can just be written alone, without writing the whole function's type. This leaves /only/ the varargs case where the explicit type is required. Given the special type syntax in call instructions, the regex-fu used for migration was a bit more involved in its own unique way (as every one of these is) so here it is. Use it in conjunction with the apply.sh script and associated find/xargs commands I've provided in rr230786 to migrate your out of tree tests. Do let me know if any of this doesn't cover your cases & we can iterate on a more general script/regexes to help others with out of tree tests. About 9 test cases couldn't be automatically migrated - half of those were functions returning function pointers, where I just had to manually delete the function argument types now that we didn't need an explicit function type there. The other half were typedefs of function types used in calls - just had to manually drop the * from those. import fileinput import sys import re pat = re.compile(r'((?:=|:|^|\s)call\s(?:[^@]*?))(\s*$|\s*(?:(?:\[\[[a-zA-Z0-9_]+\]\]|[@%](?:(")?[\\\?@a-zA-Z0-9_.]*?(?(3)"|)|{{.*}}))(?:\(|$)|undef|inttoptr|bitcast|null|asm).*$)') addrspace_end = re.compile(r"addrspace\(\d+\)\s*\*$") func_end = re.compile("(?:void.*|\)\s*)\*$") def conv(match, line): if not match or re.search(addrspace_end, match.group(1)) or not re.search(func_end, match.group(1)): return line return line[:match.start()] + match.group(1)[:match.group(1).rfind('*')].rstrip() + match.group(2) + line[match.end():] for line in sys.stdin: sys.stdout.write(conv(re.search(pat, line), line)) llvm-svn: 235145
OpenPOWER on IntegriCloud