summaryrefslogtreecommitdiffstats
path: root/polly/lib
Commit message (Collapse)AuthorAgeFilesLines
...
* [Simplify] Remove some leftover dead codeTobias Grosser2017-05-141-26/+0
| | | | llvm-svn: 303007
* [Polly] Fix code generation of llvm.expect intrinsicTobias Grosser2017-05-141-1/+0
| | | | | | | | | | | | | | | | | | | At the time of code generation, an instruction with an llvm intrinsic is ignored in copyBB. However, if the value of the instruction is used later in the program, the value needs to be synthesized. However, this is causing some issues with the instructions being generated in a hoisted basic block. Removing llvm.expect from the list of ignored intrinsics fixes this bug. This resolves http://llvm.org/PR32324. Contributed-by: Annanay Agarwal <cs14btech11001@iith.ac.in> Tags: #polly Differential Revision: https://reviews.llvm.org/D32992 llvm-svn: 303006
* [Simplify] Remove identical write removal. NFC.Michael Kruse2017-05-131-82/+2
| | | | | | | | | | | | | Removal of overwritten writes currently encompasses all the cases of the identical write removal. There is an observable behavioral change in that the last, instead of the first, MemoryAccess is kept. This should not affect the generated code, however. Differential Revision: https://reviews.llvm.org/D33143 llvm-svn: 302987
* [Simplify] Remove writes that are overwritten.Michael Kruse2017-05-131-2/+104
| | | | | | | | | | | | | | | | | | | | Remove memory writes that are overwritten by later writes. This works for StoreInsts: store double 21.0, double* %A store double 42.0, double* %A scalar writes at the end of a statement and mixes of these. Multiple writes can be the result of DeLICM, which might map multiple writes to the same location when it knows that these do no conflict (for instance because they write the same value). Such writes interfere with pattern-matched optimization such as gemm and may not get removed by other LLVM passes after code generation. Differential Revision: https://reviews.llvm.org/D33142 llvm-svn: 302986
* [Simplify] Reset all stats between runs.Michael Kruse2017-05-121-0/+3
| | | | llvm-svn: 302926
* [Polly][NewPM] Port ScopDetection to the new PassManagerPhilip Pfaffe2017-05-126-167/+222
| | | | | | | | | | | | | | | | Summary: This is a proof of concept of how to port polly-passes to the new PassManager architecture. This approach works ootb for Function-Passes, but might not be directly applicable to Scop/Region-Passes. While we could just run the Analyses/Transforms over functions instead, we'd surrender the nice pipelining behaviour we have now. Reviewers: Meinersbur, grosser Reviewed By: grosser Subscribers: pollydev, sanjoy, nemanjai, llvm-commits Tags: #polly Differential Revision: https://reviews.llvm.org/D31459 llvm-svn: 302902
* [Polly] Remove unused headerHongbin Zheng2017-05-121-2/+0
| | | | llvm-svn: 302868
* [Polly] Generate more 'canonical' induction variableHongbin Zheng2017-05-121-4/+7
| | | | | | | | | | | | | | | | | | | | | | | Today Polly generates induction variable in this way: polly.indvar = phi 0, polly.indvar.next ... polly.indvar.next = polly.indvar + stide polly.loop_cond = predicate polly.indvar, (UB - stride) Instead of: polly.indvar = phi 0, polly.indvar.next ... polly.indvar.next = polly.indvar + stide polly.loop_cond = predicate polly.indvar.next, UB The way Polly generate induction variable cause some problem in the indvar simplify pass. This patch make polly generate the later form, by assuming the induction variable never overflow Differential Revision: https://reviews.llvm.org/D33089 llvm-svn: 302866
* [DeLICM] Use input access heuristic for mapped PHI WRITEs.Michael Kruse2017-05-111-3/+18
| | | | | | | | | | | | | | | | | | | As with the scalar operand of the initial StoreInst, also use input accesses when searching for new opportunities after mapping a PHI write. The same rational applies here: After LICM has been applied, the promoted value will either be an instruction in the same statement (in which case we fall back to try every scalar access of the statement), or in another statement such that there will be such an input access. In the latter case other scalars cannot have originated from the same register promotion, at least not by LICM. This mostly helps to decrease compilation time and makes debugging easier by not pursuing unpromising routes. In some circumstances, it may change the compiler's output. llvm-svn: 302839
* [DeLICM] Lookup input accesses.Michael Kruse2017-05-112-6/+16
| | | | | | | | | | | | | | | | Previous to this patch, we used VirtualUse to determine the input access of an llvm::Value in a statement. The input access is the READ MemoryAccess that makes a value available in that statement, which can either be a READ of a MemoryKind::Value or the MemoryKind::PHI for a PHINode in the statement. DeLICM uses the input access to heuristically find a candidate to map without searching all possible values. This might modify the behaviour in that previously PHI accesses were not considered input accesses before. This was unintentially lost when "VirtualUse" was extracted from the "Known Knowledge" patch. llvm-svn: 302838
* [VirtualInstruction] Do a lookup instead of a linear search. NFC.Michael Kruse2017-05-111-20/+1
| | | | llvm-svn: 302837
* [ScopInfo] Keep scalar acceess dictionaries up-to-data. NFC.Michael Kruse2017-05-111-0/+24
| | | | | | | | | | When removing a MemoryAccess, also remove it from maps pointing to it. This was already done for InstructionToAccess, but not yet for ValueReads, ValueWrites and PHIWrites as those were only used during the ScopBuilder phase. Keeping them updated allows us to use them later as well. llvm-svn: 302836
* [Simplify] Remove identical scalar writes.Michael Kruse2017-05-111-1/+107
| | | | | | | | | | | | | | | | | | | | | | After DeLICM, it is possible to have two writes of the same value to the same location in the same statement when it determined that those writes do not conflict (write the same value). Teach -polly-simplify to remove one of the writes. It interferes with the pattern matching of matrix-multiplication kernels and also seem to not be optimized away by LLVM. The algorthm is simple, has O(n^2) behaviour (n = max number of MemoryAccesses in a statement) and only matches the most obvious cases, but seem to be enough to pattern-match Boost ublas gemm. Not handled cases include: - StoreInst instructions (a.k.a. explicit writes), since the value might be loaded or overwritten between the two stores. - PHINode, especially LCSSA, when the PHI value matches with on other's. - Partial writes (in preparation) llvm-svn: 302805
* [Simplify] Mark variables as used. NFC.Michael Kruse2017-05-101-0/+1
| | | | | | Mark one more variable as used that is needed in assertions. llvm-svn: 302726
* [Simplify] Mark variables as used. NFC.Michael Kruse2017-05-101-0/+2
| | | | | | Mark variables as used that are needed in assertions. llvm-svn: 302725
* [DeLICM] Avoid compiler warning. NFC.Michael Kruse2017-05-101-1/+1
| | | | | | | gcc 5.4 warns about using a C-style case to case away a const. Use case a const_cast instead. llvm-svn: 302715
* [DeLICM] Always normalize domain. NFC.Michael Kruse2017-05-101-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | Some isl functions can simplify their __isl_keep arguments. The argument object after the call uses different contraints to represent the same set. Different contraints can result in different outputs when printed to a string. In assert builds additional isl functions are called (in assert() or mentioned, these can change the internal representation of its read-only arguments such that printed strings are different in debug and non-debug builds. What happened here is that a call to isl_set_is_equal inside an assert in getScatterFor normalizes one of its arguments such that one redundant constraint is removed. The redundant constraint therefore does not appear in the string representing the domain, which FileCheck notices as a regression test failure compared to a build with assertions disabled. This fix removes the redundant contraints the domain from the start such that the redundant contraint is removed in assert and non-assert builds. Isl adds a flag to such sets such that the removal of redundancies is not done multiple times (here: by isl_set_is_equal). Thanks to Tobias Grosser for reporting and hinting to the cause. llvm-svn: 302711
* [Fix] [Fortran Support] Fix variable name & make testcase activate on releaseSiddharth Bhat2017-05-101-2/+2
| | | | | | | | | | | | There was: #ifdef NDEBUG This should be: #ifndef NDEBUG Also, the variable name was incorrect. Fixed the variable name. llvm-svn: 302696
* [Fortran Support] Detect Fortran arrays & metadata from dragonegg outputSiddharth Bhat2017-05-102-5/+269
| | | | | | | | | | | | | | Add the ability to tag certain memory accesses as those belonging to Fortran arrays. We do this by pattern matching against known patterns of Dragonegg's LLVM IR output from Fortran code. Fortran arrays have metadata stored with them in a struct. This struct is called the "Fortran array descriptor", and a reference to this is stored in each MemoryAccess. Differential Revision: https://reviews.llvm.org/D32639 llvm-svn: 302653
* [Polly] Canonicalize arrays according to base-ptr equivalence classTobias Grosser2017-05-104-3/+95
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: In case two arrays share base pointers in the same invariant load equivalence class, we canonicalize all memory accesses to the first of these arrays (according to their order in the equivalence class). This enables us to optimize kernels such as boost::ublas by ensuring that different references to the C array are interpreted as accesses to the same array. Before this change the runtime alias check for ublas would fail, as it would assume models of the C array with differing (but identically valued) base pointers would reference distinct regions of memory whereas the referenced memory regions were indeed identical. As part of this change we remove most of the MemoryAccess::get*BaseAddr interface. We removed already all references to get*BaseAddr in previous commits to ensure that no code relies on matching base pointers between memory accesses and scop arrays -- except for three remaining uses where we need the original base pointer. We document for these situations that MemoryAccess::getOriginalBaseAddr may return a base pointer that is distinct to the base pointer of the scop array referenced by this memory access. Reviewers: sebpop, Meinersbur, zinob, gareevroman, pollydev, huihuiz, efriedma, jdoerfert Reviewed By: Meinersbur Subscribers: etherzhhb Tags: #polly Differential Revision: https://reviews.llvm.org/D28518 llvm-svn: 302636
* Fix formatting in PollyTobias Grosser2017-05-101-3/+3
| | | | llvm-svn: 302620
* Update Polly for LLVM API change r302571 that removed varargs functionsChandler Carruth2017-05-101-2/+2
| | | | | | with a nullptr sentinel in favor of nicely typed variadic templates. llvm-svn: 302618
* [Polly][PPCGCodeGen] OpenCL now gets kernel argument size from PPCG CodeGenSiddharth Bhat2017-05-091-17/+54
| | | | | | | | | | | | | | | | Summary: PPCGCodeGeneration now attaches the size of the kernel launch parameters at the end of the parameter list. For the existing CUDA Runtime, this gets ignored, but the OpenCL Runtime knows to check for kernel-argument size at the end of the parameter list. (The resulting parameters list is twice as long. This has been accounted for in the corresponding test cases). Reviewers: grosser, Meinersbur, bollu Reviewed By: bollu Subscribers: nemanjai, yaxunl, Anastasia, pollydev, llvm-commits Tags: #polly Differential Revision: https://reviews.llvm.org/D32961 llvm-svn: 302515
* [Polly] Added OpenCL Runtime to GPURuntime Library for GPGPU CodeGenSiddharth Bhat2017-05-072-20/+114
| | | | | | | | | | | | | | | | | | | | | | | Summary: When compiling for GPU, one can now choose to compile for OpenCL or CUDA, with the corresponding polly-gpu-runtime flag (libopencl / libcudart). The GPURuntime library (GPUJIT) has been extended with the OpenCL Runtime library for that purpose, correctly choosing the corresponding library calls to the option chosen when compiling (via different initialization calls). Additionally, a specific GPU Target architecture can now be chosen with -polly-gpu-arch (only nvptx64 implemented thus far). Reviewers: grosser, bollu, Meinersbur, etherzhhb, singam-sanjay Reviewed By: grosser, Meinersbur Subscribers: singam-sanjay, llvm-commits, pollydev, nemanjai, mgorny, yaxunl, Anastasia Tags: #polly Differential Revision: https://reviews.llvm.org/D32431 llvm-svn: 302379
* [DeLICM] Known knowledge.Michael Kruse2017-05-063-61/+390
| | | | | | | | | | | | | Extend the Knowledge class to store information about the contents of array elements and which values are written. Two knowledges do not conflict the known content is the same. The content information if computed from writes to and loads from the array elements, and represented by "ValInst": isl spaces that compare equal if the value represented is the same. Differential Revision: https://reviews.llvm.org/D31247 llvm-svn: 302339
* [CMake] Introduce POLLY_BUNDLED_JSONCPP.Michael Kruse2017-05-061-7/+2
| | | | | | | | | | | Allow using a system's install jsoncpp library instead of the bundled one with the setting POLLY_BUNDLED_JSONCPP=OFF. This fixes llvm.org/PR32929 Differential Revision: https://reviews.llvm.org/D32922 llvm-svn: 302336
* [ScopBuilder] Move Scop::init to ScopBuilder. NFC.Michael Kruse2017-05-052-68/+57
| | | | | | | | | | | Scop::init is used only during SCoP construction. Therefore ScopBuilder seems the more appropriate place for it. We integrate it onto its only caller ScopBuilder::buildScop where some other construction steps already took place. Differential Revision: https://reviews.llvm.org/D32908 llvm-svn: 302276
* [ScopBuilder] Do not verify unfeasible SCoPs.Michael Kruse2017-05-051-0/+6
| | | | | | | | | | | | | | | | SCoPs with unfeasible runtime context are thrown away and therefore do not need their uses verified. The added test case requires a complexity limit to exceed. Normally, error statements are removed from the SCoP and for that reason are skipped during the verification. If there is a unfeasible runtime context (here: because of the complexity limit being reached), the removal of error statements and other SCoP construction steps are skipped to not waste time. Error statements are not modeled in SCoPs and therefore have no requirements on whether the scalars used in them are available. llvm-svn: 302234
* Fix handling of signWrappedSets in access relationsTobias Grosser2017-05-051-1/+1
| | | | | | | | | | | | | | | | | | | | | | | Since r294891, in MemoryAccess::computeBoundsOnAccessRelation(), we skip manually bounding the access relation in case the parameter of the load instruction is already a wrapped set. Later on we assume that the lower bound on the set is always smaller or equal to the upper bound on the set. Bug 32715 manages to construct a sign wrapped set, in which case the assertion does not necessarily hold. Fix this by handling a sign wrapped set similar to a normal wrapped set, that is skipping the computation. Contributed-by: Maximilian Falkenstein <falkensm@student.ethz.ch> Reviewers: grosser Subscribers: pollydev, llvm-commits Tags: #Polly Differential Revision: https://reviews.llvm.org/D32893 llvm-svn: 302231
* Revert "[Polly] Added OpenCL Runtime to GPURuntime Library for GPGPU CodeGen"Siddharth Bhat2017-05-052-114/+20
| | | | | | | | | | | | | | | This reverts commit 17a84e414adb51ee375d14836d4c2a817b191933. Patches should have been submitted in the order of: 1. D32852 2. D32854 3. D32431 I mistakenly pushed D32431(3) first. Reverting to push in the correct order. llvm-svn: 302217
* [Polly] Added OpenCL Runtime to GPURuntime Library for GPGPU CodeGenSiddharth Bhat2017-05-052-20/+114
| | | | | | | | | | | | | | | | | | | | | | | Summary: When compiling for GPU, one can now choose to compile for OpenCL or CUDA, with the corresponding polly-gpu-runtime flag (libopencl / libcudart). The GPURuntime library (GPUJIT) has been extended with the OpenCL Runtime library for that purpose, correctly choosing the corresponding library calls to the option chosen when compiling (via different initialization calls). Additionally, a specific GPU Target architecture can now be chosen with -polly-gpu-arch (only nvptx64 implemented thus far). Reviewers: grosser, bollu, Meinersbur, etherzhhb, singam-sanjay Reviewed By: grosser, Meinersbur Subscribers: singam-sanjay, llvm-commits, pollydev, nemanjai, mgorny, yaxunl, Anastasia Tags: #polly Differential Revision: https://reviews.llvm.org/D32431 llvm-svn: 302215
* [ScopBuilder] Add missing semicolon after LLVM_FALLTHROUGH.Michael Kruse2017-05-041-1/+1
| | | | | | It was forgotten in r302157. llvm-svn: 302163
* Introduce VirtualUse. NFC.Michael Kruse2017-05-044-75/+357
| | | | | | | | | | | | | | | | | | | If a ScopStmt references a (scalar) value, there are multiple possibilities where this value can come. The decision about what kind of use it is must be handled consistently at different places, which can be error-prone. VirtualUse is meant to centralize the handling of the different types of value uses. This patch makes ScopBuilder and CodeGeneration use VirtualUse. This already helps to show inconsistencies with the value handling. In order to keep this patch NFC, exceptions to the general rules are added. These might be fixed later if they turn to problems. Overall, this should result in fewer post-codegen IR-verification errors, but instead assertion failures in `getNewValue` that are closer to the actual error. Differential Revision: https://reviews.llvm.org/D32667 llvm-svn: 302157
* [ScopDetection] Check for already known required-invariant loads [NFC]Tobias Grosser2017-05-041-0/+8
| | | | | | | | | | | For certain test cases we spent over 50% of the scop detection time in checking if a load is likely invariant. We can avoid most of these checks by testing early on if a load is expected to be invariant. Doing this reduces scop-detection time on a large benchmark from 52 seconds to just 25 seconds. No functional change is expected. llvm-svn: 302134
* [ScopInfo] Do not use LLVM names to identify statements, arrays, and parametersTobias Grosser2017-05-032-27/+57
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | LLVM-IR names are commonly available in debug builds, but often not in release builds. Hence, using LLVM-IR names to identify statements or memory reference results makes the behavior of Polly depend on the compile mode. This is undesirable. Hence, we now just number the statements instead of using LLVM-IR names to identify them (this issue has previously been brought up by Zino Benaissa). However, as LLVM-IR names help in making test cases more readable, we add an option '-polly-use-llvm-names' to still use LLVM-IR names. This flag is by default set in the polly tests to make test cases more readable. This change reduces the time in ScopInfo from 32 seconds to 2 seconds for the following test case provided by Eli Friedman <efriedma@codeaurora.org> (already used in one of the previous commits): struct X { int x; }; void a(); #define SIG (int x, X **y, X **z) typedef void (*fn)SIG; #define FN { for (int i = 0; i < x; ++i) { (*y)[i].x += (*z)[i].x; } a(); } #define FN5 FN FN FN FN FN #define FN25 FN5 FN5 FN5 FN5 #define FN125 FN25 FN25 FN25 FN25 FN25 #define FN250 FN125 FN125 #define FN1250 FN250 FN250 FN250 FN250 FN250 void x SIG { FN1250 } For a larger benchmark I have on-hand (10000 loops), this reduces the time for running -polly-scops from 5 minutes to 4 minutes, a reduction by 20%. The reason for this large speedup is that our previous use of printAsOperand had a quadratic cost, as for each printed and unnamed operand the full function was scanned to find the instruction number that identifies the operand. We do not need to adjust the way memory reference ids are constructured, as they do not use LLVM values. Reviewed by: efriedma Tags: #polly Differential Revision: https://reviews.llvm.org/D32789 llvm-svn: 302072
* [ScopInfo] Remove code not needed anymore after r302004Tobias Grosser2017-05-032-7/+3
| | | | llvm-svn: 302005
* [ScopInfo] Do not add array name into memory reference idsTobias Grosser2017-05-031-10/+7
| | | | | | | | | | | | | | | | | | | | | | | | | Before this change a memory reference identifier had the form: <STMT>_<ACCESSTYPE><ID>_<MEMREF>, e.g., Stmt_bb9_Write0_MemRef_tmp11 After this change, we use the format: <STMT>_<ACCESSTYPE><ID>, e.g., Stmt_bb9_Write0 The name of the array that is accessed through a memory reference is not necessary to uniquely identify a memory reference, but was only added to provide additional information for debugging. We drop this information now for the following two reasons: 1) This shortens the names and consequently improves readability 2) This removes a second location where we decide on the name of a scop array, leaving us only with the location where the actual scop array is created. Having after 2) only a single location to name scop arrays will allow us to change the naming convention of scop arrays more easily, which we will do in a future commit to reduce compilation time. llvm-svn: 302004
* [NFC] [IslAST] fix typo: "int the" -> "in the"Siddharth Bhat2017-05-021-1/+1
| | | | llvm-svn: 301925
* [CMake] Move PollyCore to Polly project folder.Michael Kruse2017-04-301-0/+1
| | | | | | | This keeps the artifacts consistently structured in the "Polly" folder of Visual Studio solutions. llvm-svn: 301779
* [Polly] Make PollyCore depends on intrinsics_genHongbin Zheng2017-04-291-1/+1
| | | | llvm-svn: 301734
* [Codegen] Disable Polly's codegen verification by defaultTobias Grosser2017-04-281-1/+1
| | | | | | | | | | | | | | | | | As has been reported in the previous commit, codegen verification can result in quadratic compile time increases for large functions with many scops. This is certainly not something we would like to have in the Polly default configuration. Hence, we disable codegen verification by default -- also to see if this resolves some of the compilation timeouts we currently see on the AOSP buildbots. We still leave this feature in Polly as it has shown _very_ useful for debugging. In fact, we may want to have a discussion if we can bring this feature back in a way that does not impact compilation time so much. Thanks to Eli Friedman <efriedma@codeaurora.org> for reporting this issue and for providing the test case in the previous commit (where I forgot to acknowledge him). llvm-svn: 301670
* [CodeGen] Skip verify if -polly-codegen-verify is set to falseTobias Grosser2017-04-281-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | Before this change, we always tried to verify the function and printed verification errors, but just did not abort in case -polly-codegen-verify=false was set and verification failed. As verification can become very cosly -- for large functions with many scops we may verify the very same function very often -- this can affect compile time very negatively. Hence, we respect the -polly-codegen-verify flag with this check, ensuring that no verification is run if -polly-codegen-verify=false. This reduces code generation time from 26 seconds to 4 seconds on the test case below with -polly-codegen-verify=false: struct X { int x; }; void a(); #define SIG (int x, X **y, X **z) typedef void (*fn)SIG; #define FN { for (int i = 0; i < x; ++i) { (*y)[i].x += (*z)[i].x; } a(); } #define FN5 FN FN FN FN FN #define FN25 FN5 FN5 FN5 FN5 #define FN125 FN25 FN25 FN25 FN25 FN25 #define FN250 FN125 FN125 #define FN1250 FN250 FN250 FN250 FN250 FN250 void x SIG { FN1250 } llvm-svn: 301669
* [Polly] [PPCGCodeGeneration] Add managed memory support to GPU codeSiddharth Bhat2017-04-281-8/+114
| | | | | | | | | | | | | | | | | | | | | | generation. This needs changes to GPURuntime to expose synchronization between host and device. 1. Needs better function naming, I want a better name than "getOrCreateManagedDeviceArray" 2. DeviceAllocations is used by both the managed memory and the non-managed memory path. This exploits the fact that the two code paths are never run together. I'm not sure if this is the best design decision Reviewed by: PhilippSchaad Tags: #polly Differential Revision: https://reviews.llvm.org/D32215 llvm-svn: 301640
* Update to isl-0.18-592-gb50ad59Tobias Grosser2017-04-2828-331/+419
| | | | | | This is just a general maintenance update. llvm-svn: 301624
* [ScopInfo] Consider only write-free dereferencable loads as invariantTobias Grosser2017-04-271-12/+17
| | | | | | | | | | | | | When we introduced in r297375 support for hoisting loads that are known to be dereferencable without any conditional guard, we forgot to keep the check to verify that no other write into the very same location exists. This change ensures now that dereferencable loads are allowed to access everything, but can only be hoisted in case no conflicting write exists. This resolves llvm.org/PR32778 Reported-by: Huihui Zhang <huihuiz@codeaurora.org> llvm-svn: 301582
* [CMake] Use object library to build the two flavours of Polly.Michael Kruse2017-04-271-32/+78
| | | | | | | | | | | | | | | | | | | | | Polly comes in two library flavors: One loadable module to use the LLVM framework -load mechanism, and another one that host applications can link to. These have very different requirements for Polly's own dependencies. The loadable module assumes that all its LLVM dependencies are already available in the address space of the host application, and is not allowed to bring in its own copy of any LLVM library (including the NVPTX backend in case of Polly-ACC). The non-module library is intended to be linked to using target_link_libraries. CMake would then resolve all of its dependencies, including NVPTX and ensure that only a single instance of each library will be used. Differential Revision: https://reviews.llvm.org/D32442 llvm-svn: 301558
* [Polly] Do not introduce address space castHongbin Zheng2017-04-271-1/+2
| | | | | | | | Do not introduce address space cast in IslNodeBuilder::preloadUnconditionally. Differential Revision: https://reviews.llvm.org/D32581 llvm-svn: 301519
* [DeLICM] Use Known information when comparing Occupied and Written.Michael Kruse2017-04-261-22/+60
| | | | | | | | | | | | Do not conflict if a write writes the same value as already known. This change only affects unit tests, but no functional changes are expected on LLVM-IR, as no Known information is yet extracted and consequently this functionality is only triggered through unit tests. Differential Revision: https://reviews.llvm.org/D32026 llvm-svn: 301460
* Update to isl-0.18-423-g30331feTobias Grosser2017-04-264-3/+16
| | | | | | This is just a general maintenance update. llvm-svn: 301433
* [DeLICM] Use Known information when comparing Existing.Occupied and ↵Michael Kruse2017-04-251-8/+70
| | | | | | | | | | | | | | Proposed.Occupied. Do not conflict if the value of Existing and Proposed are the same. This change only affects unit tests, but no functional changes are expected on LLVM-IR, as no Known information is yet extracted and consequently this functionality is only triggered through unit tests. Differential Revision: https://reviews.llvm.org/D32025 llvm-svn: 301301
OpenPOWER on IntegriCloud