similar to: RFC: [LV] any objections in moving isLegalMasked* check from Legal to CostModel? (Cleaning up LoopVectorizationLegality)

> On 5 Jan 2018, at 21:01, Saito, Hideki via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > > All, > > I'm trying to refactor LoopVectorize such that it has better conformance to VPlan vision going forward > (http://www.llvm.org/docs/Proposals/VectorizationPlan.html). All VP*Recipe class definitions are now > moved to VPlan.h, and I have a patch under review

Amara, >I support this direction Thanks for the support. >but are there actually any real world workloads where gather/scatter scalarisation would be worth it, on any micro-architecture? If we don’t have examples and the compile time cost is non-negligible then I think we’d still like to keep the early >bailouts in some form.’ It's not like I have specific application code in

On 01/05/2018 06:28 PM, Saito, Hideki wrote: > Amara, > >> I support this direction > Thanks for the support. > >> but are there actually any real world workloads where gather/scatter scalarisation would be worth it, on any micro-architecture? If we don’t have examples and the compile time cost is non-negligible then I think we’d still like to keep the early >bailouts in

Thanks, Hal. I plan to post a patch w/o HW Legality early bailout first. That should enable further discussion on where the initial very high cost for "illegal masked load/store/gather/scatter" should be coming from --- like should LoopVectorize provide it? Or should it be provided by TTI? I prefer the latter (TTI) but the first revision of the patch will intentionally do the former

>it cannot afford large size masks for large vectors So, even a standard way of vectorizing remainder in masked or unmasked fashion wouldn’t work, I suppose. Ouch. I suppose VPlan should be able to model this kind of gigantic remainder vector code (when the time comes). Not pretty at all, though. Now, be fully aware that Direction #2 is really a poor (or rather extremely poor) person’s

Hi Hameeza, Aside from Ashutosh's patch..... When the vector width is that large, we can't keep vectorizing remainder like below. It'll be a huge code size if nothing else ---- hitting ITLB miss because of this is very bad, for example. VF=2048 // main vector loop VF=1024 // vectorized remainder 1 VF=512 // vectorized remainder 2 ... Vectorize remainder until trip count is

What LoopVectorize.cpp has are the following. Each function may have to have a separate consolidation discussion. I'm bringing up getpointerOperand() since I actually found multiple instances defined/used. DependenceAnalysis.cpp has isLoadOrStore(). LoopAccessAnalysis.cpp has getAddressSpaceOperand(). I'm sure there are others that might be worth discussing within this thread or a follow

Proposal for Outer Loop Vectorization Implementation Plan ============================================= ===== Goal: ===== Extending Loop Vectorizer (LV) such that it can handle outer loops, via VPlan infrastructure enhancements. Understand the trade-offs in trying to make concurrent progress with moving remaining inner loop vectorization functionality to VPlan infrastructure   ===========

Jonas/Renato, >I think it's mostly about the success rate, given it's too conservative. But in the past 2 years, improvements in (and around) the LV have been slowed down a bit due to the move >to VPlan. It wasn't our intention to slow down LV improvements, but if the project ended up causing other developers take the stance of wait-and-see, that's an inevitable side effect

LLVM friends, I'm currently trying to make LoopVectorizationLegality class in Transform/Vectorize/LoopVectorize.cpp more modular and eventually move it to Analysis directory tree. It uses several file scope helper functions that do not really belong to LoopVectorize. Let me start from getPointerOperand(). Within LLVM, there are five other similar functions defined. I think it's time to

Status Update on VPlan ---- where we are currently, and what's ahead of us ==========================================================   Goal: ----- Extending Loop Vectorizer (LV) such that it can handle outer loops, via uplifting its infrastructure with VPlan. The goal of this status update is to summarize the progress and the future steps needed.   Background: ----------- This is related to

"Saito, Hideki via llvm-dev" <llvm-dev at lists.llvm.org> writes: > LLVM friends, > > I'm currently trying to make LoopVectorizationLegality class in > Transform/Vectorize/LoopVectorize.cpp more modular and eventually move > it to Analysis directory tree. It uses several file scope helper > functions that do not really belong to LoopVectorize. Let me start

>Another might be to introduce changes under feature flags to ease the revert/reintroduce/revert cycle. This is essentially the first guard. We plan to have flags/settings to control which types of outer loops are handled. The new code path is initially exclusive to outer loop vectorization. If we disable all types of outer loops (and that's the initial default), LV continues to be good

To revive the discussion around vectorizer testing, here's a quick sample of a few of the issues hit recently in the loop vectorizer.  I want to be careful to say that I am not stating these are the result of any recent work, just that they're issues that have been triaged down to the loop vectorizer doing something incorrect or questionable from a performance perspective.

Hi, I found with the help of the optimization remarks a loop that could not be vectorized, but if loop distribution was enabled this may happen, which it in fact did with a very significant benchmark improvement (~25%). I tried (on SystemZ) to enable this pass, and found that it only affected a handful of files on SPEC. This means I could enable this without worrying about any regressions on

Sorry for jumping from http://lists.llvm.org/pipermail/llvm-dev/2018-September/125853.html but this is relevant. Sorry for not responding to that sooner. I was thinking about a longer reply, and time flied too quickly. >But, as I said back then, before we do so, we need to understand >exactly where to put it. That will depend on what other passes will >actually use it and if we want it

>I'm just curious as tho which concrete passes would benefit sooner. This all depends on those who are working on other loop xforms, since we currently don't have bandwidth to drive that kind of changes into other loop xforms. That's why when this line of questions pops up, I offer to work together. Short of that, the best we can proactively do is to make vectorizer analyses

On 09/13/2018 02:43 PM, Renato Golin via llvm-dev wrote: > On Thu, 13 Sep 2018 at 18:46, Saito, Hideki <hideki.saito at intel.com> wrote: >> This all depends on those who are working on other loop xforms, since we currently don't have bandwidth to drive that kind of changes into other loop xforms. That's why when this line of questions pops up, I offer to work together.

>Do you recall the arguments why it was considered a bad idea? Felt like long time ago, but it turned out that was actually just a bit over a year ago. Here's the thread. http://lists.llvm.org/pipermail/llvm-dev/2016-August/104079.html Only a few explicitly responded, but I took that as silent majority was satisfied with the responses. Prior to that thread, I also pinged HPC oriented LLVM

Hey folks, Do we have proposals for an HPC focused BoF at EuroLLVM? I'd like to discuss the current efforts around integrating Polly, parallel IR efforts and vectoriser support in VPlan (like outer loop), as well as coordination on the next steps around Flang. -- cheers, --renato