>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 available outside of vectorizer (and easy to find). In some sense, this is a chicken-egg problem. Once VPlan-based LV becomes good enough shape and if this problem still remains, we could expand into working on vectorization enabling transformations, but I really hope there are others who can work in that area before us. Hideki -----Original Message----- From: Renato Golin [mailto:renato.golin at linaro.org] Sent: Thursday, September 13, 2018 11:27 AM To: Saito, Hideki <hideki.saito at intel.com> Cc: Jonas Paulsson <paulsson at linux.vnet.ibm.com>; LLVM Dev <llvm-dev at lists.llvm.org>; Adam Nemet <anemet at apple.com>; Sanjay Patel <spatel at rotateright.com>; Ulrich Weigand <ulrich.weigand at de.ibm.com>; Zaks, Ayal <ayal.zaks at intel.com>; Caballero, Diego <diego.caballero at intel.com>; Florian Hahn <florian.hahn at arm.com> Subject: Re: Loop Distribution pass On Thu, 13 Sep 2018 at 17:33, Saito, Hideki <hideki.saito at intel.com> wrote:> Many loop optimizers (Transforms) can benefit from knowing whether the loop is legal to vectorize (or loop will vectorize). Distribution and fusion are clear examples. Vectorizer has a lot in common with unroll and jam, and we should definitely share a lot. Where to place these analyses is debatable, but my preference is having them under the Analysis tree since they are indeed analysis and in principle they shouldn't depend on Transform. I think we should start from a utility but should implement it in such a way to make it easy to convert to an analysis pass.Sure, I agree with you on that. I'm just curious as tho which concrete passes would benefit sooner. --renato
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. Short of that, the best we can proactively do is to make vectorizer analyses available outside of vectorizer (and easy to find). In some sense, this is a chicken-egg problem. Once VPlan-based LV becomes good enough shape and if this problem still remains, we could expand into working on vectorization enabling transformations, but I really hope there are others who can work in that area before us.I understand. We are working on more fundamental levels (register allocator, pipelining) before looking at the vectoriser, so it may take a while, too. Once we start looking at that, I'll let you know. cheers, --renato
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. Short of that, the best we can proactively do is to make vectorizer analyses available outside of vectorizer (and easy to find). In some sense, this is a chicken-egg problem. Once VPlan-based LV becomes good enough shape and if this problem still remains, we could expand into working on vectorization enabling transformations, but I really hope there are others who can work in that area before us. > I understand. We are working on more fundamental levels (register > allocator, pipelining) before looking at the vectoriser, so it may > take a while, too. Once we start looking at that, I'll let you know.We should probably plan to chat about this at the dev meeting next month. We'll have a few talks dealing with the future of our loop-optimization infrastructure, and the transformations therein, and this is also something that feeds into that discussion. -Hal> > cheers, > --renato > _______________________________________________ > LLVM Developers mailing list > llvm-dev at lists.llvm.org > http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev-- Hal Finkel Lead, Compiler Technology and Programming Languages Leadership Computing Facility Argonne National Laboratory