similar to: [LLVMdev] Making MipsOptimizeMathLibCalls generic

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

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

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

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.

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>

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

İ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

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

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

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 >

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

Chris Lattner wrote: > The patches I didn't apply are these: > > 1. Match (Y < 0) ? -Y : Y -> FABS in the SelectionDAGISel.cpp file. We > already catch this at the DAG level. If we aren't, please let me know. OK, no problem - I was just told last time I tried to get my patch in that this was needed because the C++ frontend generated this code, I'm generating

On Thu, 28 Apr 2005, Morten Ofstad wrote: > I have been gone for a while, finishing work on my Master's thesis... Hi Morten, congrats! :) > Now that I'm back I updated LLVM to the most recent version and found > that my FP_ABS SelectionDAGNode type and code generation was now > conflicting with the new FABS node type. I brought the rest of my local > modifications in

We've got both an sqrtf and an expf opcode in our architecture. If I call sqrt() on the C side, I see the sqrtf opcode show up in the generated assembly. However, if I call exp() on the C side, I don't see the expf opcode show up on the generated assembly, I see a call to an exp function from libm. Here's what we've got in our TargetInstrinfo.td file for both of these

sqrtf is detected by code in SelectionDAGBuilder.cpp. This gets turns into a FSQRT ISD node type that the target can handle just like any other ISD node. If the target doesn't mark ISD::FSQRT as Legal or Custom then ExpandNode in LegalizeDAG.cpp turns it back into a sqrtf libcall. On Sun, Jan 20, 2013 at 11:34 AM, David Given <dg at cowlark.com> wrote: > On 20/01/13 19:20,

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

İ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 same thing with a -O0 build? Thanks, Richard > [ 1412s] >

Eric Christopher <echristo at gmail.com> writes: > I'm not a huge fan of this because then you get to decide on a default > for all the ports, but I can understand if people want to move this > way to reduce uncertainty. FWIW, since it's one of the three targets Jim mentioned, -march=z10 is the obvious default for SystemZ. On the other hand, I think it's good to run