search for: scalarizer

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

...s OpenCL) contain vector instructions. The LLVM pass manager configuration (pass manager builder) is designed for C/C++ compilers, not for DSLs. People who use LLVM for other compilation flows (such as GPU compilers, other languages) create their own optimization pipe. I am in favor of adding the scalarizer pass so that people who build LLVM-based JITs and compilers could use it. However, I am against adding this pass by default to the pass manager builder. I understand that there are cases where scalarizing early in the pipeline is better, but I don’t think that its worth the added complexity. Ever...

Hi Michael, Thanks for testing this on your benchmarks and target. I think the results will help guide the direction we go. I tested the feature with spec2k/2k6 on AArch64/Kryo and saw minor performance swings, aside from a large (30%) improvement in spec2k6/libquantum. The primary loop in that benchmark has a conditional store, so I expected it to benefit. Regarding the cost model, I think the

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 no serious regressions this SGTM. > On Dec 13, 2016, at 5:41 AM, Matthew Simpson <mssimpso at codeaurora.org> wrote: > > Hi Michael, > > Thanks for

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

----- Original Message ----- > From: "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

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

...rites: >>> 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 in the initial version, >> and the scalarisation would still...

Conceptually speaking, I think we really ought to enable this. Practically, I'm going to test it on our benchmarks (on x86), and see if we have any regressions - this seems like a fairly major change. Re targets - let's see where we stand w.r.t regressions first. What kind of performance testing have you already run on this? Do you know of specific targets where the cost model is known to

...d <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 in the initial version, and the scalarisation would still logically be done by codegen. Would...

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