search for: scalarises

Nadav Rotem <nrotem at apple.com> writes: > On Nov 14, 2013, at 2:32 PM, Richard Sandiford > <rsandifo at linux.vnet.ibm.com> wrote: >> Richard Sandiford <rsandifo at linux.vnet.ibm.com> writes: >>> Are you worried that adding it to PMB will increase compile time? >>> The pass exits very early for any target that doesn't opt-in to doing

Hi Richard, The discussion on llvmpipe is irrelevant. llvmpipe has its own pass manager and optimization pipe, it is not a C compiler. Nadav On Nov 15, 2013, at 3:26 AM, Richard Sandiford <rsandifo at linux.vnet.ibm.com> wrote: > Nadav Rotem <nrotem at apple.com> writes: >> On Nov 14, 2013, at 2:32 PM, Richard Sandiford >> <rsandifo at linux.vnet.ibm.com>

Richard Sandiford <rsandifo at linux.vnet.ibm.com> writes: > Are you worried that adding it to PMB will increase compile time? > The pass exits very early for any target that doesn't opt-in to doing > scalarisation at the IR level, without even looking at the function. As an alternative, adding Scalarizer and InstCombine passes to SystemZPassConfig::addIRPasses() would probably

On Nov 14, 2013, at 2:32 PM, Richard Sandiford <rsandifo at linux.vnet.ibm.com> wrote: > Richard Sandiford <rsandifo at linux.vnet.ibm.com> writes: >> Are you worried that adding it to PMB will increase compile time? >> The pass exits very early for any target that doesn't opt-in to doing >> scalarisation at the IR level, without even looking at the function.

----- Original Message ----- > From: "Renato Golin" <renato.golin at linaro.org> > To: "Hal Finkel" <hfinkel at anl.gov> > Cc: "James Molloy" <James.Molloy at arm.com>, "Nadav Rotem" <nrotem at apple.com>, "Arnold Schwaighofer" > <aschwaighofer at apple.com>, "LLVM Dev" <llvm-dev at

----- Original Message ----- > From: "James Molloy" <James.Molloy at arm.com> > To: "Renato Golin" <renato.golin at linaro.org> > Cc: "Nadav Rotem" <nrotem at apple.com>, "Arnold Schwaighofer" <aschwaighofer at apple.com>, "Hal Finkel" > <hfinkel at anl.gov>, "LLVM Dev" <llvm-dev at

Hi Richard, Thanks for working on this. Comments below. > I don't understand the basis for the last statement though. Do you mean > that you think most cases produce better code if scalarised at the SD stage > rather than at the IR level? Could you give an example? You presented an example that shows that scalarizing vectors allow further optimizations. But I don’t think that

On 25 October 2013 11:06, Richard Sandiford <rsandifo at linux.vnet.ibm.com>wrote: > I wanted the same thing for SystemZ, which doesn't have vectors, > in order to improve the llvmpipe code. > Hi Richard, This is a nice patch. I was wondering how hard it'd be to do that, and it seems that you're catching lots of corner cases. My interest is also due to converting odd

Nadav Rotem <nrotem at apple.com> writes: >> I don't understand the basis for the last statement though. Do you mean >> that you think most cases produce better code if scalarised at the SD stage >> rather than at the IR level? Could you give an example? > > You presented an example that shows that scalarizing vectors allow > further optimizations. But I

Liu Xin <navy.xliu at gmail.com> writes: > Hi, LLVM community, > > I write some code in hand using LLVM IR. for simplicity, I write them in <4 > x float>. now I found some stores for elements are useless. > > for example, If I store {0.0, 1.0, 2.0, 3.0} to a <4 x float> %a. maybe > only %a.xy is alive in my program. our target doesn't feature SIMD >

Hi, LLVM community, I write some code in hand using LLVM IR. for simplicity, I write them in <4 x float>. now I found some stores for elements are useless. for example, If I store {0.0, 1.0, 2.0, 3.0} to a <4 x float> %a. maybe only %a.xy is alive in my program. our target doesn't feature SIMD instruction, which means we have to lower vector to many scalar instructions. I found

----- Original Message ----- > From: "Renato Golin" <renato.golin at linaro.org> > To: "Hal Finkel" <hfinkel at anl.gov> > Cc: "James Molloy" <James.Molloy at arm.com>, "Nadav Rotem" <nrotem at apple.com>, "Arnold Schwaighofer" > <aschwaighofer at apple.com>, "LLVM Dev" <llvm-dev at

Hi, I'd like to propose a change to our cost interfaces so that instead of returning an unsigned value from functions like getInstructionCost, getUserCost, etc., we instead return a wrapper class that encodes an integer cost along with extra state. The extra state can be used to express: 1. A cost as infinitely expensive in order to prevent certain optimisations taking place. For example,

Renato Golin <renato.golin at linaro.org> writes: > On 25 October 2013 11:06, Richard Sandiford <rsandifo at linux.vnet.ibm.com>wrote>> It would also need some TargetTransformInfo hooks to decide which >> vectors should be decomposed. > > If I got it right, this may not be necessary, or it may even be harmful. > > Say you decide that <4 x i32> vectors

Hi Richard, Thanks for working on this. We should probably move this discussion to llvm-dev because it is not strictly related to the patch review anymore. The code below is not representative of general c/c++ code. Usually only domain specific language (such as OpenCL) contain vector instructions. The LLVM pass manager configuration (pass manager builder) is designed for C/C++ compilers, not

Nadav Rotem <nrotem at apple.com> writes: > Hi Richard, > > Thanks for working on this. We should probably move this discussion to > llvm-dev because it is not strictly related to the patch review > anymore. OK, I removed phabricator and llvm-commits. > The code below is not representative of general c/c++ > code. Usually only domain specific language (such as OpenCL)

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

----- Original Message ----- > From: "Pete Cooper" <peter_cooper at apple.com> > To: "Nadav Rotem" <nrotem at apple.com> > Cc: dag at cray.com, llvmdev at cs.uiuc.edu > Sent: Friday, October 24, 2014 3:40:10 PM > Subject: Re: [LLVMdev] Adding masked vector load and store intrinsics > > On Oct 24, 2014, at 11:38 AM, Nadav Rotem < nrotem at

> 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

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