search for: hideki

...So yes, I think that would allow us to remove the VecLib mappings because we are always waiting until codegen to make the translation from generic IR to target-specific libcall. Or is there some reason that the vectorizer needs to be aware of those libcalls? On Mon, Jul 2, 2018 at 11:52 AM, Saito, Hideki <hideki.saito at intel.com> wrote: > > > Venkat, we did not invent LLVM’s VecLib functionality. The original > version of D19544 (https://reviews.llvm.org/D19544?id=55036) was indeed a > separate pass to convert widened math lib to SVML. > > Our preference for “vectorize...

On 07/02/2018 04:33 PM, Saito, Hideki wrote: > >   > > >It may not be a full solution for the problems you're trying to solve > >   > > If we are inventing a new solution, I’d like it also to solve OpenMP > declare simd legalization issue. If a small extension of existing scheme > > works for mat...

...alyses 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. Thanks, Hideki -----Original Message----- From: Renato Golin [mailto:renato.golin at linaro.org] Sent: Thursday, September 13, 2018 10:10 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 <...

...tor::isInductionPHI in the vectorizer to directly analyze the PHIs without SCEV support (mentioned by Adam) If this is the standard way to deal with all secondary inductions, it certainly looks attractive. Elena, would you try doing this and compare with 1)? Thanks, Hideki ---------------------- I looked at what our FORTRAN compiler (non-LLVM) does for the following (x, y, z, and f are float by default typing, based on names). subroutine foo(x, y, z, A, N) double precision A(N) do f = x, y, z A(f) = f enddo end The front...

Hi Hideki, I like this summary overall, thanks. More below. > On May 20, 2016, at 10:04 AM, Saito, Hideki <hideki.saito at intel.com> wrote: > > > To the best of my experience, handling case B (secondary induction) is must-have, and if I’m not mistaken, > people aren’t opposed to t...

...ctor version. But unable to decide which version to expand in the vectorizer. We needed the TTI information (ISA ). It looks like better to legalize or generate them later. regards, Venkat. On 30 June 2018 at 04:04, Sanjay Patel via llvm-dev <llvm-dev at lists.llvm.org > wrote: > Hi Hideki - > > I hinted at this problem in the summary text of https://reviews.llvm.org/ > D47610: > Why are we transforming from LLVM intrinsics to platform-specific > intrinsics in IR? I don't see the benefit. > > I don't know if it solves all of the problems you're seeing...

...ch vector ABI of interest, we need to work on the requirements and determine whether deciphering after the fact is feasible. I think we can make further progress on trivial cases (where FE doesn't "change" type) while we continue working out the details on non-trivial cases. Thanks, Hideki From: Doerfert, Johannes [mailto:jdoerfert at anl.gov] Sent: Monday, June 24, 2019 9:21 AM To: Francesco Petrogalli <Francesco.Petrogalli at arm.com>; Tian, Xinmin <xinmin.tian at intel.com> Cc: Saito, Hideki <hideki.saito at intel.com>; Simon Moll <moll at cs.uni-saarland.de&...

...torizer (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 <...

...sion is going on, I can think a bit more about how best to do HW Legality early bailout. If we are doing it, I don't think it's appropriate to limit it to masked load/store/gather/scatter. Would need some extensibility, and I think that should be discussed as a separate review. Stay Tuned. Hideki -----Original Message----- From: Hal Finkel [mailto:hfinkel at anl.gov] Sent: Saturday, January 06, 2018 9:20 PM To: Saito, Hideki <hideki.saito at intel.com>; aemerson at apple.com Cc: llvm-dev at lists.llvm.org; Demikhovsky, Elena <elena.demikhovsky at intel.com>; Amara Emerson <...

...e cases, along with changes to the vectorizer to make it aware of FP inductions. It won't get give you the powerful reasoning capabilities of SCEV, but for the B-like cases it should work. Amara On 20 May 2016 at 19:31, Adam Nemet via llvm-dev <llvm-dev at lists.llvm.org> wrote: > Hi Hideki, > > I like this summary overall, thanks. More below. > > On May 20, 2016, at 10:04 AM, Saito, Hideki <hideki.saito at intel.com> wrote: > > > To the best of my experience, handling case B (secondary induction) is > must-have, and if I’m not mistaken, > people aren...

...sing an vector of EpilogLoopInfo). If you struggle in convincing LoopVectorizationLegality to think remainder is just as legal to vectorize as main vector loop, you should be able to avoid that if you take this approach. You still have two approaches to unblock yourself in the short term. Thanks, Hideki From: hameeza ahmed [mailto:hahmed2305 at gmail.com] Sent: Friday, August 03, 2018 10:58 AM To: Saito, Hideki <hideki.saito at intel.com> Cc: Craig Topper <craig.topper at gmail.com>; Hal Finkel <hfinkel at anl.gov>; Friedman, Eli <efriedma at codeaurora.org>; ashutosh.nema...

...e deal. :) My intention is to make LV components more modular, reusable, and easier to maintain. Moving things where they actually belong is part of that picture. That makes it a lot easier for us to place those things within VPlan infrastructure and explain why that's the best place. Thanks, Hideki -----Original Message----- From: aemerson at apple.com [mailto:aemerson at apple.com] Sent: Friday, January 05, 2018 3:38 PM To: Saito, Hideki <hideki.saito at intel.com> Cc: llvm-dev at lists.llvm.org; Hal Finkel <hfinkel at anl.gov>; Demikhovsky, Elena <elena.demikhovsky at intel...

....b) or 2.c)? If we think 2.b)/2.c) are right enough directions, I can clean up what we have and upload it to Phabricator as a starting point to get to 2.b)/2.c). Continue waiting for more feedback. I guess I shouldn't expect a lot this week and next due to the big holiday in the U.S. Thanks, Hideki From: Nema, Ashutosh [mailto:Ashutosh.Nema at amd.com] Sent: Thursday, June 28, 2018 11:37 PM To: Saito, Hideki <hideki.saito at intel.com> Cc: llvm-dev at lists.llvm.org Subject: RE: [RFC][VECLIB] how should we legalize VECLIB calls? Hi Saito, At AMD we have our own version of vector libr...

...ble by other xforms than making more and more loop xforms happen inside LV. In the meantime, if those who are working on LD needs our input in tuning LD cost model, I'm more than happy to pitch in. We can also discuss what part of vectorizer analysis is helpful in LD at the same time. Thanks, Hideki -----Original Message----- From: Renato Golin [mailto:renato.golin at linaro.org] Sent: Thursday, September 13, 2018 1:48 AM To: Jonas Paulsson <paulsson at linux.vnet.ibm.com> Cc: LLVM Dev <llvm-dev at lists.llvm.org>; Adam Nemet <anemet at apple.com>; Sanjay Patel <spatel a...

...per functions either, but I suspect that trying to add those to member functions of Instruction base class has a much higher hurdle and that's probably the reason why so many different people (those who wrote the code and those who have reviewed) opted for the helper function approach. Thanks, Hideki ------------------------- // FIXME: The following helper functions have multiple implementations // in the project. They can be effectively organized in a common Load/Store // utilities unit....

...er 20-elements parts of the whole thing. I think this scenario answers Philip’s question on why separate mask and VF parameters and why VF can’t be conservatively deduced from the mask/mask compute. From: Bruce Hoult [mailto:bruce at hoult.org] Sent: Thursday, January 31, 2019 5:13 PM To: Saito, Hideki <hideki.saito at intel.com> Cc: Philip Reames <listmail at philipreames.com>; Robin Kruppe <robin.kruppe at gmail.com>; David Greene <dag at cray.com>; via llvm-dev <llvm-dev at lists.llvm.org>; Maslov, Sergey V <sergey.v.maslov at intel.com>; Topper, Craig <c...

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...

...uld not block shorter term development of vectorizer. More inputs from other optimizers would greatly help build up the context of this discussion. Please speak up if you felt similarly to us in the past. I'll be at the LLVM Conference if anyone is interested in in-person discussions. Thanks, Hideki -----Original Message----- From: Renato Golin [mailto:renato.golin at linaro.org] Sent: Monday, October 16, 2017 4:59 AM To: Hal Finkel <hfinkel at anl.gov> Cc: Daniel Berlin <dberlin at dberlin.org>; Michael Kruse <llvmdev at meinersbur.de>; llvm-dev at lists.llvm.org; Saito, H...

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...

...f bigger types and generate gather / scatter of same type. Later code generation will generate the desired instruction[s] by breaking the bigger types into target >supported. Hopefully, you can come up with a short term workaround, if the progress of Michael's work is behind yours. Thanks, Hideki -----Original Message----- From: Nema, Ashutosh [mailto:Ashutosh.Nema at amd.com] Sent: Wednesday, June 29, 2016 9:50 PM To: Saito, Hideki <hideki.saito at intel.com>; Demikhovsky, Elena <elena.demikhovsky at intel.com>; silviu.baranga at gmail.com; Zaks, Ayal <ayal.zaks at intel.c...