summaryrefslogtreecommitdiffstats
Commit message (Collapse)AuthorAgeFilesLines
* [InstCombine] fold fadd+fneg with fdiv/fmul betweenaSanjay Patel2019-07-292-8/+26
| | | | | | | | | The backend already does this via isNegatibleForFree(), but we may want to alter the fneg IR canonicalizations that currently exist, so we need to try harder to fold fneg in IR to avoid regressions. llvm-svn: 367227
* [ValueTracking] Remove volatile check in ↵Hideto Ueno2019-07-292-17/+6
| | | | | | | | | | | | | | | | | | isGuaranteedToTransferExecutionToSuccessor Summary: As clarified in D53184, volatile load and store do not trap. Therefore, we should remove volatile checks for instructions in `isGuaranteedToTransferExecutionToSuccessor`. Reviewers: jdoerfert, efriedma, nikic Reviewed By: nikic Subscribers: hiraditya, jfb, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D65375 llvm-svn: 367226
* clang-format clang/lib/FormatNico Weber2019-07-295-19/+17
| | | | llvm-svn: 367225
* [InstCombine] reduce code for fadd with fneg operand; NFCSanjay Patel2019-07-291-7/+4
| | | | llvm-svn: 367224
* [InstCombine] add tests for fadd with negated operand; NFCSanjay Patel2019-07-291-0/+362
| | | | llvm-svn: 367222
* [AMDGPU] Add amdgpu_kernel for consistency with other testsJay Foad2019-07-291-1/+1
| | | | llvm-svn: 367221
* [DAGCombine] narrowInsertExtractVectorBinOp - early out for binops that ↵Simon Pilgrim2019-07-291-0/+4
| | | | | | | | change value type. NFCI. This is implicit in the value type checks in getSubVectorSrc - this just makes it upfront and obvious. llvm-svn: 367220
* doc: Fix Google C++ Style Guide link.Rafael Stahl2019-07-291-1/+1
| | | | llvm-svn: 367219
* [DivergenceAnalysis] Add methods for querying divergence at useJay Foad2019-07-296-20/+79
| | | | | | | | | | | | | | | | | | | | | | | | | Summary: The existing isDivergent(Value) methods query whether a value is divergent at its definition. However even if a value is uniform at its definition, a use of it in another basic block can be divergent because of divergent control flow between the def and the use. This patch adds new isDivergent(Use) methods to DivergenceAnalysis, LegacyDivergenceAnalysis and GPUDivergenceAnalysis. This might allow D63953 or other similar workarounds to be removed. Reviewers: alex-t, nhaehnle, arsenm, rtaylor, rampitec, simoll, jingyue Reviewed By: nhaehnle Subscribers: jfb, jvesely, wdng, hiraditya, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D65141 llvm-svn: 367218
* [SystemZ] Regenerate <8 x i31> store testSimon Pilgrim2019-07-291-32/+33
| | | | | | To help show the diffs from an upcoming SimplifyDemandedBits patch. llvm-svn: 367216
* Mark test/MC/RISCV/rv{32,64}i-aliases-invalid.s unsupported also on WindowsHans Wennborg2019-07-292-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Because they fail there too. FAIL: LLVM :: MC/RISCV/rv32i-aliases-invalid.s (24397 of 32659) ******************** TEST 'LLVM :: MC/RISCV/rv32i-aliases-invalid.s' FAILED ******************** Script: -- : 'RUN: at line 2'; not c:\src\llvm.monorepo\build.release2\bin\llvm-mc.exe C:\src\llvm.monorepo\llvm\test\MC\RISCV\rv32i-aliases-invalid.s -triple=riscv32 -riscv-no-aliases 2>&1 | c:\src\llvm.monorepo\build.release2\bin\filecheck.exe C:\src\llvm.monorepo\llvm\test\MC\RISCV\rv32i-aliases-invalid.s : 'RUN: at line 3'; not c:\src\llvm.monorepo\build.release2\bin\llvm-mc.exe C:\src\llvm.monorepo\llvm\test\MC\RISCV\rv32i-aliases-invalid.s -triple=riscv32 2>&1 | c:\src\llvm.monorepo\build.release2\bin\filecheck.exe C:\src\llvm.monorepo\llvm\test\MC\RISCV\rv32i-aliases-invalid.s -- Exit Code: 1 Command Output (stdout): -- $ ":" "RUN: at line 2" $ "not" "c:\src\llvm.monorepo\build.release2\bin\llvm-mc.exe" "C:\src\llvm.monorepo\llvm\test\MC\RISCV\rv32i-aliases-invalid.s" "-triple=riscv32" "-riscv-no-aliases" $ "c:\src\llvm.monorepo\build.release2\bin\filecheck.exe" "C:\src\llvm.monorepo\llvm\test\MC\RISCV\rv32i-aliases-invalid.s" C:\src\llvm.monorepo\llvm\test\MC\RISCV\rv32i-aliases-invalid.s:10:21: error: CHECK: expected string not found in input li t4, foo # CHECK: :[[@LINE]]:8: error: immediate must be an integer in the range [-2147483648, 4294967295] ^ <stdin>:5:1: note: scanning from here li x0, -2147483649 # CHECK: :[[@LINE]]:8: error: immediate must be an integer in the range [-2147483648, 4294967295] ^ <stdin>:5:1: note: with "@LINE" equal to "10" li x0, -2147483649 # CHECK: :[[@LINE]]:8: error: immediate must be an integer in the range [-2147483648, 4294967295] ^ <stdin>:5:38: note: possible intended match here li x0, -2147483649 # CHECK: :[[@LINE]]:8: error: immediate must be an integer in the range [-2147483648, 4294967295] ^ error: command failed with exit status: 1 -- -- ******************** Testing: 0 .. 10.. 20.. 30.. 40.. 50.. 60.. 70 FAIL: LLVM :: MC/RISCV/rv64i-aliases-invalid.s (24416 of 32659) ******************** TEST 'LLVM :: MC/RISCV/rv64i-aliases-invalid.s' FAILED ******************** Script: -- : 'RUN: at line 2'; not c:\src\llvm.monorepo\build.release2\bin\llvm-mc.exe C:\src\llvm.monorepo\llvm\test\MC\RISCV\rv64i-aliases-invalid.s -triple=riscv64 -riscv-no-aliases 2>&1 | c:\src\llvm.monorepo\build.release2\bin\filecheck.exe C:\src\llvm.monorepo\llvm\test\MC\RISCV\rv64i-aliases-invalid.s : 'RUN: at line 3'; not c:\src\llvm.monorepo\build.release2\bin\llvm-mc.exe C:\src\llvm.monorepo\llvm\test\MC\RISCV\rv64i-aliases-invalid.s -triple=riscv64 2>&1 | c:\src\llvm.monorepo\build.release2\bin\filecheck.exe C:\src\llvm.monorepo\llvm\test\MC\RISCV\rv64i-aliases-invalid.s -- Exit Code: 1 Command Output (stdout): -- $ ":" "RUN: at line 2" $ "not" "c:\src\llvm.monorepo\build.release2\bin\llvm-mc.exe" "C:\src\llvm.monorepo\llvm\test\MC\RISCV\rv64i-aliases-invalid.s" "-triple=riscv64" "-riscv-no-aliases" $ "c:\src\llvm.monorepo\build.release2\bin\filecheck.exe" "C:\src\llvm.monorepo\llvm\test\MC\RISCV\rv64i-aliases-invalid.s" C:\src\llvm.monorepo\llvm\test\MC\RISCV\rv64i-aliases-invalid.s:6:21: error: CHECK: expected string not found in input li t4, foo # CHECK: :[[@LINE]]:8: error: operand must be a constant 64-bit integer ^ <stdin>:2:1: note: scanning from here li t5, 0x10000000000000000 # CHECK: :[[@LINE]]:8: error: unknown operand ^ <stdin>:2:1: note: with "@LINE" equal to "6" li t5, 0x10000000000000000 # CHECK: :[[@LINE]]:8: error: unknown operand ^ <stdin>:13:67: note: possible intended match here C:\src\llvm.monorepo\llvm\test\MC\RISCV\rv64i-aliases-invalid.s:12:13: error: immediate must be an integer in the range [0, 63] ^ error: command failed with exit status: 1 llvm-svn: 367215
* [ARM] Regenerate rotation testsSimon Pilgrim2019-07-291-5/+8
| | | | llvm-svn: 367214
* [AMDGPU] Regenerate v2i16 insertelement tests. Simon Pilgrim2019-07-291-337/+1557
| | | | | | To help show the diffs from an upcoming SimplifyDemandedBits patch. llvm-svn: 367213
* [NFC][ARM[ParallelDSP] Cleanup of BinOpChainSam Parker2019-07-291-81/+58
| | | | | | | | | | | | - Remove some unused typedefs. - Rename BinOpChain struct to MulCandidate. - Remove the size method of MulCandidate. - Store only the first input of the ValueList provided to MulCandidate, as it's the only value we care about. This means we don't have to perform any ugly (and unnecessary) iterations of the list later on. llvm-svn: 367208
* [lldb][NFC] Split emitting and parsing in LLDBOptionDefEmitterRaphael Isemann2019-07-291-42/+80
| | | | | | | | Splitting the different logic is cleaner and we it will be easier to implement the enum emitting (which otherwise would have to reimplement the Record parsing). llvm-svn: 367207
* [AMDGPU] Enable v4f16 and above for v_pk_fma instructionsDavid Stuttard2019-07-294-84/+214
| | | | | | | | | | | | | | | | | | | | Summary: If isel is presented with <2 x half> vectors then it will correctly select v_pk_fma style instructions. If isel is presented with e.g. <4 x half> vectors it will scalarize, unlike for other instruction types (such as fadd, fmul etc.) Added extra support to enable this. Updated one of the tests to include a test for this (as well as extending the test to GFX9) Subscribers: arsenm, kzhuravl, jvesely, wdng, nhaehnle, yaxunl, tpr, t-tye, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D65325 Change-Id: I50a4577a3f8223fb53992af3b7d26121f65b71ee llvm-svn: 367206
* [NFC][ARM][ParallelDSP] Remove AreSymmetricalSam Parker2019-07-291-43/+0
| | | | | | | We explicitly search for a parallel mac and we only care about its inputs, checking for symmetry doesn't add anything here. llvm-svn: 367205
* [NFC][ARM][ParallelDSP] Remove PopulateLoadsSam Parker2019-07-291-9/+0
| | | | | | | | We no longer have to check what loads are used, all this is performed at the start of the transform, so it's not doing anything now. llvm-svn: 367204
* [obj2yaml] - Report a error when unable to resolve a sh_link reference properly.George Rimar2019-07-292-2/+64
| | | | | | | | | Because of a bug we did not report a error in the case shown in the test. With this patch we do. Differential revision: https://reviews.llvm.org/D65214 llvm-svn: 367203
* [llvm-objcopy] - Reimplement strip-dwo-groups.test to stop using the ↵George Rimar2019-07-292-35/+71
| | | | | | | | | | | | | | | | precompiled object. When llvm-copy removes .dwo sections the index of symbol table, the indices of the symbols and the indices of the sections which go after the removed ones changes. That affects on SHT_GROUP sections, which needs to be updated. Initially this test used a precompiled object, I rewrote it to use YAML and improved a bit. Differential revision: https://reviews.llvm.org/D65273 llvm-svn: 367202
* [lldb][NFC] Remove DiagnosticManager::CopyDiagnosticsRaphael Isemann2019-07-292-11/+0
| | | | | | | | | The Diagnostic class in LLDB is suppossed to be inherited from, so just copying the diagnostics like this is wrong. The function is also unused, so lets just get rid of it instead of creating some cloning facility for it. llvm-svn: 367201
* Return early. NFC.Rui Ueyama2019-07-291-10/+10
| | | | llvm-svn: 367200
* Improve MSVC visualizers for DeclSpec and TemplateNameMike Spertus2019-07-291-2/+79
| | | | | | | | DeclSpec now shows the TypeRep, ExprRep, or DeclRep as appropriate TemplateName decodes and displays the StorageType A few minor refinements to other types llvm-svn: 367199
* [X86] Don't use PMADDWD for vector add reductions of multiplies if the mul ↵Craig Topper2019-07-292-26/+36
| | | | | | | | | | | | | | | | | | | | | inputs have an additional user. The pmaddwd inserts a truncate, if that truncate would end up creating additional instructions instead of making a zext narrower, then we shouldn't do it. I've restricted this to only sse4.1 targets since on prior targets the zext will be done in stages. So the truncate will probably not create additional instructions. Might need some more investigation of mul shrinking and the other pmaddwd transform to be sure this is the right decision. There might be a slight regression on AVX1 targets due to add splitting. Hard to say for sure. Maybe we need to look into using the vector reduction flag to use 2 narrow loads and a blend instead of extracting and inserting. llvm-svn: 367198
* [X86] Add test cases to show missing one use check in combineLoopMAddPattern.Craig Topper2019-07-291-0/+132
| | | | llvm-svn: 367197
* [NFC][InstCombine] Revisit tests in ↵Roman Lebedev2019-07-281-70/+35
| | | | | | shift-amount-reassociation-with-truncation-shl.ll llvm-svn: 367196
* [X86] In combineLoopMAddPattern and combineLoopSADPattern, preserve the ↵Craig Topper2019-07-283-95/+80
| | | | | | | | | | vector reduction flag on the final add. Handle unrolled loops by letting DAG combine revisit. This reverts r340478 and r340631 and replaces them with a simpler method of just letting DAG combine revisit the nodes to handle the other operand. llvm-svn: 367195
* [InstCombine] fold fsub+fneg with fdiv/fmul betweenSanjay Patel2019-07-282-8/+23
| | | | | | | | | The backend already does this via isNegatibleForFree(), but we may want to alter the fneg IR canonicalizations that currently exist, so we need to try harder to fold fneg in IR to avoid regressions. llvm-svn: 367194
* Buildbot fix for r367190Gabor Borsik2019-07-281-1/+1
| | | | llvm-svn: 367193
* [ARM] MVE VPNOTDavid Green2019-07-286-215/+75
| | | | | | | | | | This adds the patterns required to transform xor P0, -1 to a VPNOT. The instruction operands have to change a little for this, adding an in and an out VCCR reg and using a custom DecodeMVEVPNOT for the decode. Differential Revision: https://reviews.llvm.org/D65133 llvm-svn: 367192
* [ARM] Better patterns for fp <> predicate vectorsDavid Green2019-07-283-68/+93
| | | | | | | | | | These are some better patterns for converting between predicates and floating points. Much like the extends, we select "1"/"-1" or "0" depending on the predicate value. Or we perform a compare against 0 to convert to a predicate. Differential Revision: https://reviews.llvm.org/D65103 llvm-svn: 367191
* [analyzer] Add yaml parser to GenericTaintCheckerGabor Borsik2019-07-288-25/+327
| | | | | | | | | | | | | | | | | | | | | While we implemented taint propagation rules for several builtin/standard functions, there's a natural desire for users to add such rules to custom functions. A series of patches will implement an option that allows users to annotate their functions with taint propagation rules through a YAML file. This one adds parsing of the configuration file, which may be specified in the commands line with the analyzer config: alpha.security.taint.TaintPropagation:Config. The configuration may contain propagation rules, filter functions (remove taint) and sink functions (give a warning if it gets a tainted value). I also added a new header for future checkers to conveniently read YAML files as checker options. Differential Revision: https://reviews.llvm.org/D59555 llvm-svn: 367190
* [NFC][InstCombine] Shift amount reassociation: can have trunc between shl'sRoman Lebedev2019-07-281-0/+289
| | | | | | | | | https://rise4fun.com/Alive/OQbM Not so simple for lshr/ashr, so those maybe later. https://bugs.llvm.org/show_bug.cgi?id=42391 llvm-svn: 367189
* Don't initialize interceptor_metadata_map unless SI_POSIX is setEugene Leviant2019-07-281-1/+3
| | | | | | Differential revision: https://reviews.llvm.org/D64794 llvm-svn: 367188
* [Attributor] Deduce "align" attributeHideto Ueno2019-07-286-5/+434
| | | | | | | | | | | | | | | | | Summary: Deduce "align" attribute in attributor. Reviewers: jdoerfert, sstefan1 Reviewed By: jdoerfert Subscribers: hiraditya, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D64152 llvm-svn: 367187
* [lldb] Also include the array definition in CommandOptions.incRaphael Isemann2019-07-2820-196/+26
| | | | | | | | | | | | | | | | | | | | | | | | | Summary: Right now our CommandOptions.inc only generates the initializer for the options list but not the array declaration boilerplate around it. As the array definition is identical for all arrays, we might as well also let the CommandOptions.inc generate it alongside the initializers. This patch will also allow us to generate additional declarations related to that option list in the future (e.g. a enum class representing the specific options which would make our handling code less prone). This patch also fixes a few option tables that didn't follow our naming style. Reviewers: JDevlieghere Reviewed By: JDevlieghere Subscribers: abidh, lldb-commits Tags: #lldb Differential Revision: https://reviews.llvm.org/D65331 llvm-svn: 367186
* [IR] Fix getPointerAlignment for CallBaseHideto Ueno2019-07-281-3/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: In current getPointerAlignemnt implementation, CallBase.getPointerAlignement(..) checks only parameter attriutes in the callsite. For example, ``` declare align 8 i8* @foo() define void @bar() { %a = tail call align 8 i8* @foo() ; getPointerAlignment returns 8 %b = tail call i8* @foo() ; getPointerAlignemnt returns 0 ret void } ``` This patch will fix the problem. Reviewers: jdoerfert Reviewed By: jdoerfert Subscribers: hiraditya, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D65281 llvm-svn: 367185
* [FunctionAttrs] Annotate "willreturn" for intrinsicsHideto Ueno2019-07-2828-218/+210
| | | | | | | | | | | | | | | | | | | Summary: In D62801, new function attribute `willreturn` was introduced. In short, a function with `willreturn` is guaranteed to come back to the call site(more precise definition is in LangRef). In this patch, willreturn is annotated for LLVM intrinsics. Reviewers: jdoerfert Reviewed By: jdoerfert Subscribers: jvesely, nhaehnle, sstefan1, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D64904 llvm-svn: 367184
* Fix PR35637: suboptimal codegen for `vector<unsigned char>`.Eric Fiselier2019-07-283-95/+86
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The optimizer is petulant and temperamental. In this case LLVM failed to lower the the "insert at end" loop used by`vector<unsigned char>` to a `memset` despite `memset` being substantially faster over a range of bytes. LLVM has the ability to lower loops to `memset` whet appropriate, but the odd nature of libc++'s loops prevented the optimization from taking places. This patch addresses the issue by rewriting the loops from the form `do [ ... --__n; } while (__n > 0);` to instead use a for loop over a pointer range (For example: `for (auto *__i = ...; __i < __e; ++__i)`). This patch also rewrites the asan annotations to unposion all additional memory at the start of the loop instead of once per iterations. This could potentially permit false negatives where the constructor of element N attempts to access element N + 1 during its construction. The before and after results for the `BM_ConstructSize/vector_byte/5140480_mean` benchmark (run 5 times) are: -------------------------------------------------------------------------------------------- Benchmark Time CPU Iterations -------------------------------------------------------------------------------------------- Before ------ BM_ConstructSize/vector_byte/5140480_mean 12530140 ns 12469693 ns N/A BM_ConstructSize/vector_byte/5140480_median 12512818 ns 12445571 ns N/A BM_ConstructSize/vector_byte/5140480_stddev 106224 ns 107907 ns 5 ----- After ----- BM_ConstructSize/vector_byte/5140480_mean 167285 ns 166500 ns N/A BM_ConstructSize/vector_byte/5140480_median 166749 ns 166069 ns N/A BM_ConstructSize/vector_byte/5140480_stddev 3242 ns 3184 ns 5 llvm-svn: 367183
* [Driver] Additional fixup of NOWARN test case from r367165Bjorn Pettersson2019-07-271-1/+1
| | | | | | | | | | | | Same kind of fix as in r367176, but for "RUN on line 76" this time. I'll ask for a post-commit review, to ensure this matches the intention with the test added in r367165. But I think this at least will make the buildbots a little bit happier. llvm-svn: 367182
* [DAGCombine] narrowInsertExtractVectorBinOp - early out for illegal op. NFCI.Simon Pilgrim2019-07-271-1/+4
| | | | | | If the subvector binop is illegal then early-out and avoid the subvector searches. llvm-svn: 367181
* Stricter check for the memory access.Joerg Sonnenberger2019-07-271-1/+3
| | | | | | | | The current pattern would trigger for scheduling changes of the post-load computation, since those are commutable with the inline asm. Avoid this by explicitly check the order of load vs asm block. llvm-svn: 367180
* Regenerate UXTB testsSimon Pilgrim2019-07-272-81/+157
| | | | llvm-svn: 367179
* [clangd] Fix NDEBUG build problem introduced by rL366698Bjorn Pettersson2019-07-271-1/+8
| | | | | | | | | | | | Sprinkled some #ifndef NDEBUG in Selection.cpp to make it possible to build with NDEBUG defined. The problem was introduced in rL366698 when using dlog for some debug printouts. The dlog macro expands to DEBUG_WITH_TYPE, which isn't using it's arguments in optimized builds (when NDEBUG is defined). llvm-svn: 367178
* [Driver] Fix "unannotated fall-through between switch labels". NFCBjorn Pettersson2019-07-271-0/+1
| | | | | | Just a simple fix of Werror problem after r367165. llvm-svn: 367177
* Attempt to make test in r367165 more robust.Nico Weber2019-07-271-2/+2
| | | | | | | | | | | | | | | | | | | | | | | Some people were seeing this failure: ``` : 'RUN: at line 83'; clang -mrelax-all -fno-integrated-as /b/s/w/ir/k/llvm-project/clang/test/Driver/as-options.s -S 2>&1 \ | /FileCheck --check-prefix=WARN --allow-empty clang/test/Driver/as-options.s -- Exit Code: 1 Command Output (stderr): -- clang/test/Driver/as-options.s:66:16: error: NOWARN-NOT: excluded string found in input // NOWARN-NOT: unused ^ <stdin>:1:95: note: found here clang-10: warning: clang/test/Driver/as-options.s: 'assembler' input unused [-Wunused-command-line-argument] ``` Maybe this helps with that. llvm-svn: 367176
* [AMDGPU] Regenerate tests. Simon Pilgrim2019-07-273-314/+1767
| | | | | | To help show the diffs from an upcoming SimplifyDemandedBits patch. llvm-svn: 367175
* [TargetLowering] SimplifyMultipleUseDemandedBits - add BITCAST pass through ↵Simon Pilgrim2019-07-276-457/+431
| | | | | | | | | | | | support (Reapplied) This allows us to peek through BITCASTs, attempt to simplify the source operand, and then bitcast back. This reapplies rL367091 which was reverted at rL367118 - we were inconsistently peeking through the bitcasts to the source value. Fixes PR42777 llvm-svn: 367174
* [InstSimplify] remove quadratic time looping (PR42771)Sanjay Patel2019-07-272-25/+21
| | | | | | | | | | | | | | | | | | | | The test case from: https://bugs.llvm.org/show_bug.cgi?id=42771 ...shows a ~30x slowdown caused by the awkward loop iteration (rL207302) that is seemingly done just to avoid invalidating the instruction iterator. We can instead delay instruction deletion until we reach the end of the block (or we could delay until we reach the end of all blocks). There's a test diff here for a degenerate case with llvm.assume that is not meaningful in itself, but serves to verify this change in logic. This change probably doesn't result in much overall compile-time improvement because we call '-instsimplify' as a standalone pass only once in the standard -O2 opt pipeline currently. Differential Revision: https://reviews.llvm.org/D65336 llvm-svn: 367173
* [X86][SSE] Replace PMULDQ GetDemandedBits combine with ↵Simon Pilgrim2019-07-271-9/+12
| | | | | | | | SimplifyMultipleUseDemandedBits handler (Reapplied) Recommit rL367100 which was reverted at rL367141. Until PR42777 is fixed, we no longer get the benefits of peeking through bitcasts but it does still remove a GetDemandedBits user and gives us the equivalent combines. llvm-svn: 367172
OpenPOWER on IntegriCloud