summaryrefslogtreecommitdiffstats
path: root/llvm/lib/Transforms/Vectorize
Commit message (Collapse)AuthorAgeFilesLines
...
* Do not restrict interleaved unrolling to small loops, depending on the target.Olivier Sallenave2015-03-061-0/+8
| | | | llvm-svn: 231528
* Make DataLayout Non-Optional in the ModuleMehdi Amini2015-03-043-8/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: DataLayout keeps the string used for its creation. As a side effect it is no longer needed in the Module. This is "almost" NFC, the string is no longer canonicalized, you can't rely on two "equals" DataLayout having the same string returned by getStringRepresentation(). Get rid of DataLayoutPass: the DataLayout is in the Module The DataLayout is "per-module", let's enforce this by not duplicating it more than necessary. One more step toward non-optionality of the DataLayout in the module. Make DataLayout Non-Optional in the Module Module->getDataLayout() will never returns nullptr anymore. Reviewers: echristo Subscribers: resistor, llvm-commits, jholewinski Differential Revision: http://reviews.llvm.org/D7992 From: Mehdi Amini <mehdi.amini@apple.com> llvm-svn: 231270
* Make ToVectorTy static.Michael Zolotukhin2015-03-021-11/+9
| | | | llvm-svn: 231007
* SLPVectorizer: Rewrite ArrayRef slice compare to be more idiomatic.Benjamin Kramer2015-03-021-9/+5
| | | | | | NFC intended. llvm-svn: 230965
* Remove DebugLoc::print(LLVMContext, raw_ostream), it was justEric Christopher2015-02-261-1/+1
| | | | | | forwarding to the one that didn't take a context. llvm-svn: 230700
* [LoopAccesses] Change LAA:getInfo to return a constant referenceAdam Nemet2015-02-191-3/+3
| | | | | | | | As expected, this required a few more const-correctness fixes. Based on Hal's feedback on D7684. llvm-svn: 229899
* [LoopAccesses] Split out LoopAccessReport from VectorizerReportAdam Nemet2015-02-191-7/+26
| | | | | | | | | | | | The only difference between these two is that VectorizerReport adds a vectorizer-specific prefix to its messages. When LAA is used in the vectorizer context the prefix is added when we promote the LoopAccessReport into a VectorizerReport via one of the constructors. This is part of the patchset that converts LoopAccessAnalysis into an actual analysis pass. llvm-svn: 229897
* [LoopAccesses] Add missing const to APIs in VectorizationReportAdam Nemet2015-02-191-2/+2
| | | | | | | | | | When I split out LoopAccessReport from this, I need to create some temps so constness becomes necessary. This is part of the patchset that converts LoopAccessAnalysis into an actual analysis pass. llvm-svn: 229896
* [LoopAccesses] Change debug messages from LV to LAAAdam Nemet2015-02-191-2/+2
| | | | | | | | | Also add pass name as an argument to VectorizationReport::emitAnalysis. This is part of the patchset that converts LoopAccessAnalysis into an actual analysis pass. llvm-svn: 229894
* [LoopAccesses] Create the analysis passAdam Nemet2015-02-191-17/+25
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This is a function pass that runs the analysis on demand. The analysis can be initiated by querying the loop access info via LAA::getInfo. It either returns the cached info or runs the analysis. Symbolic stride information continues to reside outside of this analysis pass. We may move it inside later but it's not a priority for me right now. The idea is that Loop Distribution won't support run-time stride checking at least initially. This means that when querying the analysis, symbolic stride information can be provided optionally. Whether stride information is used can invalidate the cache entry and rerun the analysis. Note that if the loop does not have any symbolic stride, the entry should be preserved across Loop Distribution and LV. Since currently the only user of the pass is LV, I just check that the symbolic stride information didn't change when using a cached result. On the LV side, LoopVectorizationLegality requests the info object corresponding to the loop from the analysis pass. A large chunk of the diff is due to LAI becoming a pointer from a reference. A test will be added as part of the -analyze patch. Also tested that with AVX, we generate identical assembly output for the testsuite (including the external testsuite) before and after. This is part of the patchset that converts LoopAccessAnalysis into an actual analysis pass. llvm-svn: 229893
* [LoopAccesses] Cache the result of canVectorizeMemoryAdam Nemet2015-02-191-2/+2
| | | | | | | | | | | | LAA will be an on-demand analysis pass, so we need to cache the result of the analysis. canVectorizeMemory is renamed to analyzeLoop which computes the result. canVectorizeMemory becomes the query function for the cached result. This is part of the patchset that converts LoopAccessAnalysis into an actual analysis pass. llvm-svn: 229892
* [LoopAccesses] Stash the report from the analysis rather than emitting itAdam Nemet2015-02-191-2/+6
| | | | | | | | | | | The transformation passes will query this and then emit them as part of their own report. The currently only user LV is modified to do just that. This is part of the patchset that converts LoopAccessAnalysis into an actual analysis pass. llvm-svn: 229891
* [LoopAccesses] Make VectorizerParams global + fix for cyclic depAdam Nemet2015-02-191-24/+6
| | | | | | | | | | | | | | | | | As LAA is becoming a pass, we can no longer pass the params to its constructor. This changes the command line flags to have external storage. These can now be accessed both from LV and LAA. VectorizerParams is moved out of LoopAccessInfo in order to shorten the code to access it. This commits also has the fix (D7731) to the break dependence cycle between the analysis and vector libraries. This is part of the patchset that converts LoopAccessAnalysis into an actual analysis pass. llvm-svn: 229890
* Revert "Reformat."Adam Nemet2015-02-191-19/+31
| | | | | | | | | | This reverts commit r229651. I'd like to ultimately revert r229650 but this reformat stands in the way. I'll reformat the affected files once the the loop-access pass is fully committed. llvm-svn: 229889
* Reformat.NAKAMURA Takumi2015-02-181-31/+19
| | | | llvm-svn: 229651
* Revert r229622: "[LoopAccesses] Make VectorizerParams global" and others. ↵NAKAMURA Takumi2015-02-181-70/+37
| | | | | | | | | | | | | | | | | | r229622 brought cyclic dependencies between Analysis and Vector. r229622: "[LoopAccesses] Make VectorizerParams global" r229623: "[LoopAccesses] Stash the report from the analysis rather than emitting it" r229624: "[LoopAccesses] Cache the result of canVectorizeMemory" r229626: "[LoopAccesses] Create the analysis pass" r229628: "[LoopAccesses] Change debug messages from LV to LAA" r229630: "[LoopAccesses] Add canAnalyzeLoop" r229631: "[LoopAccesses] Add missing const to APIs in VectorizationReport" r229632: "[LoopAccesses] Split out LoopAccessReport from VectorizerReport" r229633: "[LoopAccesses] Add -analyze support" r229634: "[LoopAccesses] Change LAA:getInfo to return a constant reference" r229638: "Analysis: fix buildbots" llvm-svn: 229650
* [LoopAccesses] Change LAA:getInfo to return a constant referenceAdam Nemet2015-02-181-3/+3
| | | | | | | | As expected, this required a few more const-correctness fixes. Based on Hal's feedback on D7684. llvm-svn: 229634
* [LoopAccesses] Split out LoopAccessReport from VectorizerReportAdam Nemet2015-02-181-7/+26
| | | | | | | | | | | | The only difference between these two is that VectorizerReport adds a vectorizer-specific prefix to its messages. When LAA is used in the vectorizer context the prefix is added when we promote the LoopAccessReport into a VectorizerReport via one of the constructors. This is part of the patchset that converts LoopAccessAnalysis into an actual analysis pass. llvm-svn: 229632
* [LoopAccesses] Add missing const to APIs in VectorizationReportAdam Nemet2015-02-181-2/+2
| | | | | | | | | | When I split out LoopAccessReport from this, I need to create some temps so constness becomes necessary. This is part of the patchset that converts LoopAccessAnalysis into an actual analysis pass. llvm-svn: 229631
* [LoopAccesses] Change debug messages from LV to LAAAdam Nemet2015-02-181-2/+2
| | | | | | | | | Also add pass name as an argument to VectorizationReport::emitAnalysis. This is part of the patchset that converts LoopAccessAnalysis into an actual analysis pass. llvm-svn: 229628
* [LoopAccesses] Create the analysis passAdam Nemet2015-02-181-17/+25
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This is a function pass that runs the analysis on demand. The analysis can be initiated by querying the loop access info via LAA::getInfo. It either returns the cached info or runs the analysis. Symbolic stride information continues to reside outside of this analysis pass. We may move it inside later but it's not a priority for me right now. The idea is that Loop Distribution won't support run-time stride checking at least initially. This means that when querying the analysis, symbolic stride information can be provided optionally. Whether stride information is used can invalidate the cache entry and rerun the analysis. Note that if the loop does not have any symbolic stride, the entry should be preserved across Loop Distribution and LV. Since currently the only user of the pass is LV, I just check that the symbolic stride information didn't change when using a cached result. On the LV side, LoopVectorizationLegality requests the info object corresponding to the loop from the analysis pass. A large chunk of the diff is due to LAI becoming a pointer from a reference. A test will be added as part of the -analyze patch. Also tested that with AVX, we generate identical assembly output for the testsuite (including the external testsuite) before and after. This is part of the patchset that converts LoopAccessAnalysis into an actual analysis pass. llvm-svn: 229626
* [LoopAccesses] Make blockNeedsPredication staticAdam Nemet2015-02-181-2/+4
| | | | | | | | | | | | | | | | blockNeedsPredication is in LoopAccess in order to share it with the vectorizer. It's a utility needed by LoopAccess not strictly provided by it but it's a good place to share it. This makes the function static so that it no longer required to create an LoopAccessInfo instance in order to access it from LV. This was actually causing problems because it would have required creating LAI much earlier that LV::canVectorizeMemory(). This is part of the patchset that converts LoopAccessAnalysis into an actual analysis pass. llvm-svn: 229625
* [LoopAccesses] Cache the result of canVectorizeMemoryAdam Nemet2015-02-181-2/+2
| | | | | | | | | | | | LAA will be an on-demand analysis pass, so we need to cache the result of the analysis. canVectorizeMemory is renamed to analyzeLoop which computes the result. canVectorizeMemory becomes the query function for the cached result. This is part of the patchset that converts LoopAccessAnalysis into an actual analysis pass. llvm-svn: 229624
* [LoopAccesses] Stash the report from the analysis rather than emitting itAdam Nemet2015-02-181-2/+6
| | | | | | | | | | | The transformation passes will query this and then emit them as part of their own report. The currently only user LV is modified to do just that. This is part of the patchset that converts LoopAccessAnalysis into an actual analysis pass. llvm-svn: 229623
* [LoopAccesses] Make VectorizerParams globalAdam Nemet2015-02-181-15/+17
| | | | | | | | | | | | | | As LAA is becoming a pass, we can no longer pass the params to its constructor. This changes the command line flags to have external storage. These can now be accessed both from LV and LAA. VectorizerParams is moved out of LoopAccessInfo in order to shorten the code to access it. This is part of the patchset that converts LoopAccessAnalysis into an actual analysis pass. llvm-svn: 229622
* [LoopAccesses] Rename LoopAccessAnalysis to LoopAccessInfoAdam Nemet2015-02-181-15/+15
| | | | | | | | | LoopAccessAnalysis will be used as the name of the pass. This is part of the patchset that converts LoopAccessAnalysis into an actual analysis pass. llvm-svn: 229621
* Enabled cost calculation for masked memory operations.Elena Demikhovsky2015-02-151-1/+5
| | | | | | | We already have implementation for cost calculation for masked memory operations. I just call it from the loop vectorizer. llvm-svn: 229290
* Transforms: Canonicalize access to function attributes, NFCDuncan P. N. Exon Smith2015-02-141-3/+2
| | | | | | | | | | | | Canonicalize access to function attributes to use the simpler API. getAttributes().getAttribute(AttributeSet::FunctionIndex, Kind) => getFnAttribute(Kind) getAttributes().hasAttribute(AttributeSet::FunctionIndex, Kind) => hasFnAttribute(Kind) llvm-svn: 229202
* [PM] Remove the old 'PassManager.h' header file at the top level ofChandler Carruth2015-02-131-1/+1
| | | | | | | | | | | | | | | | | | | | LLVM's include tree and the use of using declarations to hide the 'legacy' namespace for the old pass manager. This undoes the primary modules-hostile change I made to keep out-of-tree targets building. I sent an email inquiring about whether this would be reasonable to do at this phase and people seemed fine with it, so making it a reality. This should allow us to start bootstrapping with modules to a certain extent along with making it easier to mix and match headers in general. The updates to any code for users of LLVM are very mechanical. Switch from including "llvm/PassManager.h" to "llvm/IR/LegacyPassManager.h". Qualify the types which now produce compile errors with "legacy::". The most common ones are "PassManager", "PassManagerBase", and "FunctionPassManager". llvm-svn: 229094
* [slp] Fix a nasty bug in the SLP vectorizer that Joerg pointed out.Chandler Carruth2015-02-121-4/+16
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Apparently some code finally started to tickle this after my canonicalization changes to instcombine. The bug stems from trying to form a vector type out of scalars that aren't compatible at all. In this example, from x86_mmx values. The code in the vectorizer that checks for reasonable types whas checking for aggregates or vectors, but there are lots of other types that should just never reach the vectorizer. Debugging this was made more confusing by the lie in an assert in VectorType::get() -- it isn't that the types are *primitive*. The types must be integer, pointer, or floating point types. No other types are allowed. I've improved the assert and added a helper to the vectorizer to handle the element type validity checks. It now re-uses the VectorType static function and then further excludes weird target-specific types that we probably shouldn't be touching here (x86_fp80 and ppc_fp128). Neither of these are really reachable anyways (neither 80-bit nor 128-bit things will get vectorized) but it seems better to just eagerly exclude such nonesense. I've added a test case, but while it definitely covers two of the paths through this code there may be more paths that would benefit from test coverage. I'm not familiar enough with the SLP vectorizer to synthesize test cases for all of these, but was able to update the code itself by inspection. llvm-svn: 228899
* Use ADDITIONAL_HEADER_DIRS in all LLVM CMake projects.Zachary Turner2015-02-111-0/+3
| | | | | | | | | | This allows IDEs to recognize the entire set of header files for each of the core LLVM projects. Differential Revision: http://reviews.llvm.org/D7526 Reviewed By: Chris Bieneman llvm-svn: 228798
* Correctly combine alias.scope metadata by a union instead of intersectingBjorn Steinbrink2015-02-081-0/+2
| | | | | | | | | | | | | | | | | Summary: The alias.scope metadata represents sets of things an instruction might alias with. When generically combining the metadata from two instructions the result must be the union of the original sets, because the new instruction might alias with anything any of the original instructions aliased with. Reviewers: hfinkel Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D7490 llvm-svn: 228525
* [LV] Move addRuntimeCheck to LoopAccessAnalysisAdam Nemet2015-02-061-104/+5
| | | | | | | | | | | | | This will allow it to be shared with the new Loop Distribution pass. getFirstInst is currently duplicated across LoopVectorize.cpp and LoopAccessAnalysis.cpp. This is a short-term work-around until we figure out a better solution. NFC. (The code moved is adjusted a bit for the name of the Loop member and that PtrRtCheck is now a reference rather than a pointer.) llvm-svn: 228418
* [LV] Split off memcheck block really at the first checkAdam Nemet2015-02-031-1/+1
| | | | | | | | | | | I've noticed this while trying to move addRuntimeCheck to LoopAccessAnalysis. I think that the intention was to early exit from the overflow checking before the code for the memchecks. This is the entire reason why we compute FirstCheckInst but then we don't use that as the splitting instruction but the final check. Looks like an oversight. llvm-svn: 228056
* [LoopVectorize] Fix rebase glitch in r227751Adam Nemet2015-02-031-5/+3
| | | | | | | | | LoopVectorizationLegality::{getNumLoads,getNumStores} should forward to LoopAccessAnalysis now. Thanks to Takumi for noticing this! llvm-svn: 227992
* Resurrect initializers for NumLoads and NumStores in ↵NAKAMURA Takumi2015-02-031-2/+3
| | | | | | | LoopVectorizationLegality to suppress undefined behavior. FIXME: Shall they be managed in LAA? llvm-svn: 227940
* Fix: SLPVectorizer crashes with assertion when vectorizing a cmp instruction.Erik Eckstein2015-02-021-0/+1
| | | | | | | | | The commit r225977 uncovered this bug. The problem was that the vectorizer tried to read the second operand of an already deleted instruction. The bug didn't show up before r225977 because the freed memory still contained a non-null pointer. With r225977 deletion of instructions is delayed and the read operand pointer is always null. llvm-svn: 227800
* LoopVectorize: Remove initializer list that blocks MSVC.Benjamin Kramer2015-02-011-4/+4
| | | | llvm-svn: 227766
* [LoopVectorize] Move LoopAccessAnalysis to its own moduleAdam Nemet2015-02-011-1216/+1
| | | | | | | | | | | | | | | | | | | | Other than moving code and adding the boilerplate for the new files, the code being moved is unchanged. There are a few global functions that are shared with the rest of the LoopVectorizer. I moved these to the new module as well (emitLoopAnalysis, stripIntegerCast, replaceSymbolicStrideSCEV) along with the Report class used by emitLoopAnalysis. There is probably room for further improvement in this area. I kept DEBUG_TYPE "loop-vectorize" because it's used as the PassName with emitOptimizationRemarkAnalysis. This will obviously have to change. NFC. This is part of the patchset that splits out the memory dependence logic from LoopVectorizationLegality into a new class LoopAccessAnalysis. LoopAccessAnalysis will be used by the new Loop Distribution pass. llvm-svn: 227756
* [LoopVectorize] Move RuntimePointerCheck under LoopAccessAnalysisAdam Nemet2015-02-011-44/+49
| | | | | | | | | | | This class needs to remain public because it's used by LoopVectorizationLegality::addRuntimeCheck. NFC. This is part of the patchset that splits out the memory dependence logic from LoopVectorizationLegality into a new class LoopAccessAnalysis. LoopAccessAnalysis will be used by the new Loop Distribution pass. llvm-svn: 227755
* [LoopVectorize] Pass parameters explicitly to MemoryDepCheckerAdam Nemet2015-02-011-14/+51
| | | | | | | | | | | | | | | Rather than using globals use a structure to pass parameters from the vectorizer. This prepares the class to be moved outside the LoopVectorizer. It's not great how all this is passed through in LoopAccessAnalysis but this is all expected to change once the class start servicing the Loop Distribution pass as well where some of these parameters make no sense. NFC. This is part of the patchset that splits out the memory dependence logic from LoopVectorizationLegality into a new class LoopAccessAnalysis. LoopAccessAnalysis will be used by the new Loop Distribution pass. llvm-svn: 227754
* [LoopVectorize] Split out LoopAccessAnalysis from LoopVectorizationLegalityAdam Nemet2015-02-011-18/+85
| | | | | | | | | | | | | | Move the canVectorizeMemory functionality from LoopVectorizationLegality to a new class LoopAccessAnalysis and forward users. Currently the collection of the symbolic stride information is kept with LoopVectorizationLegality and it becomes an input to LoopAccessAnalysis. NFC. This is part of the patchset that splits out the memory dependence logic from LoopVectorizationLegality into a new class LoopAccessAnalysis. LoopAccessAnalysis will be used by the new Loop Distribution pass. llvm-svn: 227751
* [LoopVectorize] Add accessors for Num{Stores,Loads,PredStores} in AccessAnalysisAdam Nemet2015-02-011-7/+18
| | | | | | | | | | | These members are moving to LoopAccessAnalysis. The accessors help to hide this. NFC. This is part of the patchset that splits out the memory dependence logic from LoopVectorizationLegality into a new class LoopAccessAnalysis. LoopAccessAnalysis will be used by the new Loop Distribution pass. llvm-svn: 227750
* [LoopVectorize] Rename the Report class to VectorizationReportAdam Nemet2015-02-011-50/+72
| | | | | | | | | | | This class will become public in the new LoopAccessAnalysis header so the name needs to be more global. NFC. This is part of the patchset that splits out the memory dependence logic from LoopVectorizationLegality into a new class LoopAccessAnalysis. LoopAccessAnalysis will be used by the new Loop Distribution pass. llvm-svn: 227749
* [LoopVectorize] Factor out duplicated code into Report::emitAnalysisAdam Nemet2015-02-011-10/+16
| | | | | | | | | | | The logic in emitAnalysis is duplicated across multiple functions. This splits it into a function. Another use will be added by the patchset. NFC. This is part of the patchset that splits out the memory dependence logic from LoopVectorizationLegality into a new class LoopAccessAnalysis. LoopAccessAnalysis will be used by the new Loop Distribution pass. llvm-svn: 227748
* [LoopVectorize] Split out RuntimePointerCheck from LoopVectorizationLegalityAdam Nemet2015-02-011-46/+47
| | | | | | | | | | | | RuntimePointerCheck will be used through LoopAccessAnalysis in LoopVectorizationLegality. Later in the patchset it will become a local class of LoopAccessAnalysis. NFC. This is part of the patchset that splits out the memory dependence logic from LoopVectorizationLegality into a new class LoopAccessAnalysis. LoopAccessAnalysis will be used by the new Loop Distribution pass. llvm-svn: 227747
* [multiversion] Thread a function argument through all the callers of theChandler Carruth2015-02-013-6/+7
| | | | | | | | | | | | | | getTTI method used to get an actual TTI object. No functionality changed. This just threads the argument and ensures code like the inliner can correctly look up the callee's TTI rather than using a fixed one. The next change will use this to implement per-function subtarget usage by TTI. The changes after that should eliminate the need for FTTI as that will have become the default. llvm-svn: 227730
* [PM] Change the core design of the TTI analysis to use a polymorphicChandler Carruth2015-01-313-10/+14
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | type erased interface and a single analysis pass rather than an extremely complex analysis group. The end result is that the TTI analysis can contain a type erased implementation that supports the polymorphic TTI interface. We can build one from a target-specific implementation or from a dummy one in the IR. I've also factored all of the code into "mix-in"-able base classes, including CRTP base classes to facilitate calling back up to the most specialized form when delegating horizontally across the surface. These aren't as clean as I would like and I'm planning to work on cleaning some of this up, but I wanted to start by putting into the right form. There are a number of reasons for this change, and this particular design. The first and foremost reason is that an analysis group is complete overkill, and the chaining delegation strategy was so opaque, confusing, and high overhead that TTI was suffering greatly for it. Several of the TTI functions had failed to be implemented in all places because of the chaining-based delegation making there be no checking of this. A few other functions were implemented with incorrect delegation. The message to me was very clear working on this -- the delegation and analysis group structure was too confusing to be useful here. The other reason of course is that this is *much* more natural fit for the new pass manager. This will lay the ground work for a type-erased per-function info object that can look up the correct subtarget and even cache it. Yet another benefit is that this will significantly simplify the interaction of the pass managers and the TargetMachine. See the future work below. The downside of this change is that it is very, very verbose. I'm going to work to improve that, but it is somewhat an implementation necessity in C++ to do type erasure. =/ I discussed this design really extensively with Eric and Hal prior to going down this path, and afterward showed them the result. No one was really thrilled with it, but there doesn't seem to be a substantially better alternative. Using a base class and virtual method dispatch would make the code much shorter, but as discussed in the update to the programmer's manual and elsewhere, a polymorphic interface feels like the more principled approach even if this is perhaps the least compelling example of it. ;] Ultimately, there is still a lot more to be done here, but this was the huge chunk that I couldn't really split things out of because this was the interface change to TTI. I've tried to minimize all the other parts of this. The follow up work should include at least: 1) Improving the TargetMachine interface by having it directly return a TTI object. Because we have a non-pass object with value semantics and an internal type erasure mechanism, we can narrow the interface of the TargetMachine to *just* do what we need: build and return a TTI object that we can then insert into the pass pipeline. 2) Make the TTI object be fully specialized for a particular function. This will include splitting off a minimal form of it which is sufficient for the inliner and the old pass manager. 3) Add a new pass manager analysis which produces TTI objects from the target machine for each function. This may actually be done as part of #2 in order to use the new analysis to implement #2. 4) Work on narrowing the API between TTI and the targets so that it is easier to understand and less verbose to type erase. 5) Work on narrowing the API between TTI and its clients so that it is easier to understand and less verbose to forward. 6) Try to improve the CRTP-based delegation. I feel like this code is just a bit messy and exacerbating the complexity of implementing the TTI in each target. Many thanks to Eric and Hal for their help here. I ended up blocked on this somewhat more abruptly than I expected, and so I appreciate getting it sorted out very quickly. Differential Revision: http://reviews.llvm.org/D7293 llvm-svn: 227669
* Silence "not all paths return a value" warning in MSVCReid Kleckner2015-01-301-0/+1
| | | | llvm-svn: 227614
* Fix a warning introduced by r227557 due to a default label in a fullyChandler Carruth2015-01-301-1/+0
| | | | | | covering switch. llvm-svn: 227575
OpenPOWER on IntegriCloud