search for: scalarized

Hi, A number of transforms are actually independent, so here's a partial fix. I updated the dependencies in a cluster of transforms: LowerSwitch, Mem2Reg, LowerSelect, LowerAllocations, UnifyFunctionExitNodes. The patch has been tested, but not extensively. PassManager doesn't complain, and the result of a test pass that requires all these (except for LowerAllocations) together works

I was trying to add some stronger assertions in the verifier around !tbaa metadata when I ran into an ambiguity: I think the encoding of the metadata nodes are such that a given node can be interpreted as either a struct type node or a scalar tbaa node. I'd like a sanity check before I try to fix or work around this. Consider some IR that I got from running clang over a small C++ program:

We should find a code owner for the scalarizer (lib/Transforms/Scalar/Scalarizer.cpp). I nominate Richard Sandiford, who added it in r195471. Let me know what you think. Thanks, Hans

On Wed, Jul 15, 2015 at 1:10 PM, Daniel Berlin <dberlin at dberlin.org> wrote: > IMHO, This doesn't make a lot of sense to turn off this part on it's own. > I would just use the enable-pre flag to turn off scalar PRE, as it > will cause the same issue in other cases as well. > Is there some reason you aren't just doing that? > I suspect if this is a performance

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

...clearly beneficial? > > (+Arnold, who probably knows why this is disabled by default. :-) ) > > Thanks, > Michael > > On Mon, Dec 12, 2016 at 2:52 PM, Matthew Simpson <mssimpso at codeaurora.org> > wrote: > >> Hi, >> >> I'd like to enable the scalarized conditional stores feature in the loop >> vectorizer (-enable-cond-stores-vec=true). The feature allows us to >> vectorize loops containing conditional stores that must be scalarized and >> predicated in the vectorized loop. >> >> Note that this flag does not affect th...

...ough, so it's clearly beneficial? > > (+Arnold, who probably knows why this is disabled by default. :-) ) > > Thanks, > Michael > > On Mon, Dec 12, 2016 at 2:52 PM, Matthew Simpson <mssimpso at codeaurora.org> wrote: > Hi, > > I'd like to enable the scalarized conditional stores feature in the loop vectorizer (-enable-cond-stores-vec=true). The feature allows us to vectorize loops containing conditional stores that must be scalarized and predicated in the vectorized loop. > > Note that this flag does not affect the decision to generate masked vect...

Hello, How can I compute the functions on the loop iterators used as array indices?  For example: for i = 0, N       for j = 0, M             A[2*i + j - 10] = ...  Can I obtain that this instruction A[2*i + j - 10]= .. always accesses memory using a function       f(i,j)   =   2*i + j - 10 + base_address_of_A If I run the scalar evolution pass on this code I obtain: %arrayidx =

That should be literally impossible, which makes me think something was tested wrong The second patch i posted disables scalar pre (assuming you use -disable-pre) but not load pre. Since the patch you reverted touched only scalar pre, disabling scalar pre should *also* do the same thing. On Thu, Jul 16, 2015 at 5:43 PM, Lawrence <lawrence at codeaurora.org> wrote: > Hi, Daniel: >

I am needing to return i128 as a shadow return due to abi issues on alpha.  The problem I am running into is the code for doing that with scalars (currently only used for vectors, as far as I can tell) sets the sret on the parameter.  If I just go this path, then I am setting sret on an integer pointer, which verify objects too.  LangRef doesn't say scalars are allowed to have sret set, but

On Tue, 2009-06-23 at 22:55 -0700, Nick Lewycky wrote: > Mai, Haohui wrote: > > Hi all, > > > > I'm working on a project which tries to prove an access to an array is > > safe. For example, > > > > int foo(int s) { > > int * p = malloc(s * sizeof int); > > ... > > int q = p[s - 2]; > > } > > > > then the access

...t;Arnold Schwaighofer via llvm-dev" <llvm-dev at lists.llvm.org> > To: "Matthew Simpson" <mssimpso at codeaurora.org> > Cc: "llvm-dev" <llvm-dev at lists.llvm.org> > Sent: Tuesday, December 13, 2016 9:17:08 AM > Subject: Re: [llvm-dev] Enabling scalarized conditional stores in the loop vectorizer > > I added this feature for libquantum > (http://llvm.org/viewvc/llvm-project?view=revision&revision=200270) > waiting for an update to the cost model modeling the scalarization > of stores which you recently added. > > Assuming...

Hello Tobi, You are right, we need to run some other passes before running the scalar evolution pass. The sequence that I run for this example is -O3 -loop-simplify -reg2mem.  This is why I did not obtain the expressions depending on the loop indices. So I removed the reg2mem pass and scalar evolution computes the correct functions. However, I need to run the reg2mem pass (or any other that

I just upgraded our optimizer to LLVM 3.0 from 2.8 and noticed that the scalar replacement of aggregates pass takes a lot longer for some code. Has there been a performance regression in this pass, or does it do more work? LLVM 3.0: Total Execution Time: 1.0600 seconds (1.0526 wall clock) ---User Time--- --System Time-- --User+System-- ---Wall Time--- --- Name --- 0.5100

Hi all, I'm working on a project which tries to prove an access to an array is safe. For example, int foo(int s) { int * p = malloc(s * sizeof int); ... int q = p[s - 2]; } then the access of p[s - 2] always stays in bound. I implemented a prototype using the Scalar Evolution pass. Here are the pseudo-code of the implementation: const SCEV * offset =

On Sun, Jul 16, 2017, 12:45 PM Nuno Lopes <nunoplopes at sapo.pt> wrote: > >On 07/15/2017 04:51 AM, Nuno Lopes wrote: > >>> On 07/14/2017 04:37 PM, Nuno Lopes wrote: > >>>> Thank you all for your replies. > >>>> So here seems to be an agreement that the documentation for > >>>> PartialAlias is incorrect. > >>>>

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

...e cost model is known to be good enough, so it's clearly beneficial? (+Arnold, who probably knows why this is disabled by default. :-) ) Thanks, Michael On Mon, Dec 12, 2016 at 2:52 PM, Matthew Simpson <mssimpso at codeaurora.org> wrote: > Hi, > > I'd like to enable the scalarized conditional stores feature in the loop > vectorizer (-enable-cond-stores-vec=true). The feature allows us to > vectorize loops containing conditional stores that must be scalarized and > predicated in the vectorized loop. > > Note that this flag does not affect the decision to genera...

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

I have a question about the SSE scalar convert intrinsics. cvtsd2si is defined thusly: def int_x86_sse2_cvtsd2si64 : GCCBuiltin<"__builtin_ia32_cvtsd2si64">, Intrinsic<[llvm_i64_ty, llvm_v2f64_ty], [IntrNoMem]>; This matches the signature of the GCC intrinsic. The fact that the GCC intrinsic has a type mismatch on the input (vector rather than scalar) is