search for: scalarisation

...<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. >> >> As an alternative, adding Scalarizer and InstCombine passes to >> SystemZPassConfig::addIRPasses() would probably give me most of the >> benefit without affecting the PMB. Scalarizer itself would then not >&gt...

...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. >>> >>> As an alternative, adding Scalarizer and InstCombine passes to >>> SystemZPassConfig::addIRPasses() would probably give me most of the >>> benefit without affecting the PMB. Scalarizer itself would...

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 give me most of the benefit without affecting the PMB. Scalarizer itself would then not test TargetTransformInfo at all, at least i...

...chard 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. > > As an alternative, adding Scalarizer and InstCombine passes to > SystemZPassConfig::addIRPasses() would probably give me most of the > benefit without affecting the PMB. Scalarizer itself would then not > test TargetTransfo...

...fast-math flags on the instructions generated. This might require some frontend enablement work, so be it. There might be a slight issue with legacy IR bitcode, but if that's going to be a problem in practice, we can design some scheme to let auto-upgrade do the right thing. > > If the scalarisation is in IR, then any NEON intrinsic in C code will > get wrongly scalarised. Builtins can be lowered in either IR > operations or builtins, and the back-end has no way of knowing the > origin. > > If the scalarization is lower down, then we risk also changing inline > ASM snippets,...

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

...generation for c++ programs or > for programs from another domain ? Both. Or more precisely: I want vector input to be optimised wherever it comes from. 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. Thanks, Richard

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

...;llvm-dev at lists.llvm.org>, "nd" <nd at arm.com> > Sent: Wednesday, February 10, 2016 8:30:50 AM > Subject: Re: Vectorization with fast-math on irregular ISA sub-sets > > On 9 February 2016 at 20:29, Hal Finkel <hfinkel at anl.gov> wrote: > >> If the scalarisation is in IR, then any NEON intrinsic in C code > >> will > >> get wrongly scalarised. Builtins can be lowered in either IR > >> operations or builtins, and the back-end has no way of knowing the > >> origin. > >> > >> If the scalarization is lower...

...aking place. For example, there are already examples in LLVM where the cost is set extremely high, but not so high that it would cause overflow. This might be to prevent vectorisation in cases where we would have to scalarize the operation, which is particularly relevant for scalable vectors, where scalarisation is not [yet] available. There isn't currently a standard value for something that constitutes very expensive and we can replace all the magic numbers with a single invalid state. 2. A cost as unknown, where the user is simply unable to determine an accurate cost for an operation. This new wrap...

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

...gt; of later (CodeGen) constant propagation, but that isn't as easy for > more complicated chains of operations. > > This wasn't a motivation, but: I believe there's a long-term plan > to move away from SelectionDAG-based instruction selection. I was > hoping that doing scalarisation at the IR level would help with that. >

...port, and if the front end cares about the performance of that vector code, it should explicitly run the Scalarizer pass itself. AIUI, it would also be the front end's resposnsibility to identify which targets have support for which vector widths and which would instead use scalarisation. That seems to be a less clean interface. E.g. as things stand today, llvmpipe is able to do everything it needs to do with generic IR. Porting it to a new target is a very trivial change of a few lines[*]. This seems like a good endorsement of the current interface. But the interface would be l...

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 mind. This all depends on what your code has and how...

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

...uld be able to disable/enable it under an option. > > Let me know what you think. > > Thanks, > Hideki Saito > > I support this direction, and agree in principal that these are strictly cost model queries, 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.’ Amara

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 some form.’ > It's not like I have specific application code in mind. This all depends on what your code has and...