similar to: Code owner for the scalarizer

I think the people that have been in there the most are Hal and Chandler of late with a few others here and there. -eric On Wed, Aug 19, 2015 at 10:30 AM Chris Lattner via llvm-dev < llvm-dev at lists.llvm.org> wrote: > > > On Aug 19, 2015, at 9:50 AM, Hans Wennborg <hans at chromium.org> wrote: > > > > We should find a code owner for the scalarizer > >

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>

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.

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

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

Richard Sandiford wrote: >I'd like to step down as code owner for the SystemZ port and nominate >Ulrich Weigand to take over. Sorry for not doing this sooner. I'd be happy to take over that role. Thanks for all your work on SystemZ, Richard! Bye, Ulrich

I propose that we make Akira Hatanaka the code owner for the Mips code generator. He has worked on the Mips code generator for four years now and done high quality work that whole time. He is the key person inside of Mips for reviewing patches and giving advice to other developers regarding new Mips work. To assure the future quality of the Mips port, I think it makes sense to formalize

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

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

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

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

I don't know...now I have a _X. in my CDR. -----Original Message----- From: Matthew Boehm [mailto:mboehm@cytelcom.com] Sent: Saturday, March 12, 2005 8:05 PM To: Asterisk Developers Mailing List <asterisk-dev@lists.digium.com> Subject: Re: [Asterisk-Dev] SetVarCDR You must have some fux0red config 'cause using _X. works fine here. I haven't had an 's' in my CDRs for

Hi, On Thu, Nov 21, 2013 at 8:16 PM, Richard Sandiford < rsandifo at linux.vnet.ibm.com> wrote: > İsmail Dönmez <ismail at donmez.ws> writes: > > Using openSUSE 13.1 on s390x machine I get two new regressions with llvm > > 3.4rc1: > > Hmm, I don't see this locally. Just to rule out one possibility, > which compiler are you using to build? Do you see the

Hi, Great to see someone working on this. This will benefit the performance portability goal of the pocl's OpenCL kernel compiler. It has been one of the low hanging fruits in improving its implicit WG vectorization applicability. The use case there is that sometimes it makes sense to devectorize the explicitly used vector datatype code of OpenCL kernels in order to make better opportunities

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

Ping. Richard Sandiford <rsandifo at linux.vnet.ibm.com> writes: > MipsOptimizeMathLibCalls.cpp converts: > > g = sqrt (f); > > into: > > r1 = sqrt (f) readonly; > if (g is a NaN) > r2 = sqrt (f); > g = phi (r1, r2) > > I'd like to do the same on z. Would it be OK to make this pass generic > and do the transformation whenever FSQRT

İsmail Dönmez <ismail at donmez.ws> writes: > On Thu, Nov 21, 2013 at 8:16 PM, Richard Sandiford < > rsandifo at linux.vnet.ibm.com> wrote: >> İsmail Dönmez <ismail at donmez.ws> writes: >> > Using openSUSE 13.1 on s390x machine I get two new regressions with llvm >> > 3.4rc1: >> >> Hmm, I don't see this locally. Just to rule out one

Pekka Jääskeläinen <pekka.jaaskelainen at tut.fi> writes: > E.g., the last time I checked, the inner loop vectorizer (which pocl exploits) > just refused to vectorize loops with vector instructions. It might not > be so drastic with the SLP or the BB vectorizer, but in general, it might > make sense to let the vectorizer to do the decisions on how to map the > parallel

Hi, Richard, I think we are solving a same problem. I am working on shader language too. I am not satisfied with current binaries because vector operations are kept in llvm opt. glsl shader language has an operation called "swizzle". It can select sub-components of a vector. If a shader only takes components "xy" for a vec4. it's certainly wasteful to generate 4

On 02/25/2014 09:30 AM, Richard Sandiford wrote: > reed kotler <rkotler at mips.com> writes: >> On 02/24/2014 04:42 PM, Eric Christopher wrote: >>> On Mon, Feb 24, 2014 at 4:40 PM, reed kotler <rkotler at mips.com> wrote: >>>> I need to leave soon and will take a look in the morning. >>>> >>>> I did look at the autoconf input files