search for: inductively

Eli Friedman <eli.friedman <at> gmail.com> writes: > >> > I did not mention in the original email (and should have) that OSR needs > >> > -instcombine to be run after it for cleanup. Also -licm, -reassociate, -gvn > >> > and -sccp can be enabling optimizations for OSR. > >> > >> Hmm... perhaps that could be partially fixed

On 4 February 2013 18:25, Arnold Schwaighofer <aschwaighofer at apple.com>wrote: > For cases where this approach breaks really badly we could consider adding > a specialized api or parameters (like the type of a user/use). But we > should do so only as a last resort and backed by actual code that would > benefit from doing so. > Very sensible, more or less what I had in

Hello, I've just downloaded the latest release of LLVM, and playing with the following simple example: int main() { int r(0); for (int i = 0; i < 100; ++i) r += i; ; return r; } I compile it and then run: analyze -indvars x.bc which prints: Printing analysis 'Induction Variable Analysis' for function 'main': and nothing else. It is a

Hello LLVM, Can you suggest a good way to use the loops and induction variable passes to map loop exiting BasicBlocks to InductionVariables. That is, can we use these tools to identify the loop condition. What i have tried Function Pass: foreach BB if(terminal is loop exit of containing loop) trace back to instruction producing the cond that the branch branches on -

> Can you suggest a good way to use the loops and induction variable > passes to map loop exiting BasicBlocks to InductionVariables. That is, > can we use these tools to identify the loop condition. I can try. :) It looks like you're running into problems because we don't perform "Linear Function Test Replacement". This optimization would reduce the amount of code

Hi all, My take on this is that, as you state below, at the IR level we are only roughly estimating cost, at best (or we would have to lower the code and then estimate cost - something we don't want to do). I would propose for estimating the "worst case costs" and see how far we get with this. My rational here is that we don't want vectorization to decrease performance relative

Hi all, The IndVarSimplify pass seems to be too aggressive when it enlarge the induction variable type ; this can pessimize the generated code when the new induction variable size is not natively supported by the target. This is probably not an issue for x86_64, which supports natively all types, but it is a real one for several embedded targets, with very few native types. I attached a patch to

On Wed, 31 Mar 2004, Vladimir Prus wrote: > I've just downloaded the latest release of LLVM, and playing with the > following simple example: > > int main() > { > int r(0); > for (int i = 0; i < 100; ++i) > r += i; > ; > return r; > } When I compiled it, I got the following LLVM code: int %main() { entry: call void %__main( )

Hi, I am using Scalar Evolution to extract access expressions (for load and store instructions) in terms of the loop induction variables. I observe that the Scalar Evolution analysis is returning more expressions than I expect - including ones that are not defined in terms of the loop induction variable. For instance in the following code: for(unsigned long int bid = 0; bid < no_of_queries;

But even for a very simple loop: int test1 (int *x, int *y, int *z, int k) { int sum = 0; for (int i = 10; i < k; i++) { z[i] = x[i] / y[i]; } return sum; } The initial value of induction variable is not zero after compiling with -O3 -mcpu=power8 x.cpp -S -c -emit-llvm -fno-unroll-loops (see bottom of the email for IR) Also I can write somewhat more complicated loop where step

----- Original Message ----- > From: "Renato Golin" <renato.golin at linaro.org> > To: "Arnold Schwaighofer" <aschwaighofer at apple.com> > Cc: "LLVM Dev" <llvmdev at cs.uiuc.edu>, "Nadav Rotem" <nrotem at apple.com>, "Hal Finkel" <hfinkel at anl.gov> > Sent: Monday, February 4, 2013 1:38:03 PM >

Hi, I was looking at trying to get loop induction variable at IR level. LLVM documentation mentioned indvars pass and getCanonicalInductionVariable() to get them, I tried running the indvars pass and then a custom pass which iterates through loops and uses the function to obtain variable for a simple loop program. But the API returns null. I also read in similar posts that the indvars pass is not

Hi, I'm working now on extending SCEV Analysis and adding FP support. At the beginning, I want to vectorize this loop: float fp_inc; float x = init; for (int i=0;i<N;i++){ A[i] = x; x += fp_inc; // Loop invariant variable or constant } In this loop "x" is a FP induction variable. But it is not the "primary" induction and loop trip count is still depends

Hi folks, I've been thinking on how to implement some of the costs and there is a lot of instructions which cost depend on other instructions around. Casts are one obvious case, since arithmetic and memory instructions can, sometimes, cast values for free. The cost model receives Opcodes, which lose the info on the history of the values being vectorized, and I thought we could pass the whole

The loop vectorized does not estimate the cost of vectorization by looking at the IR you list below. It does not vectorize and then run the CostAnalysis pass. It estimates the cost itself before it even performs the vectorization. The way it works is that it looks at all the scalar instructions and asks: What is the cost if I execute the scalar instruction as a vector instruction. Therefore, it

Hi Fellows, The goal is to find the induction variable for a loop, where the induction variable increments with the multiplication, division or shift operations, like this one: sz = 8; do { ... ... sz = sz / 2; } while (sz) Is SCEV capable of detecting the induction variable 'sz' in this case? The code snippet I am using to solve the problem is for each basic-block in a

This support was removed years ago from indvars. We don't need canonical induction variables any more as all analysis are done on SCEVs. The SCEV generator can transform them even without the need for explicit canonical induction variables. Best, Tobias On Wed, Aug 9, 2017, at 14:23, Anastasiya Ruzhanskaya via llvm-dev wrote: > The files of this strange pass are described here >

On Fri, Oct 29, 2010 at 11:18 AM, Brian West <bnwest at rice.edu> wrote: > Eli Friedman <eli.friedman <at> gmail.com> writes: >> >> > I did not mention in the original email (and should have) that OSR >> >> > needs >> >> > -instcombine to be run after it for cleanup. Also -licm, >> >> > -reassociate, -gvn >>

Hi Hashim, Scalar evolution determines evolution of scalar in terms of expression chain driving it. Try dumping the detailed log using opt -analyze -scalar-evolution <.ll> -S , and look for LoopDispositions corresponding to different expression which shows variance characteristics of a particular expression w.r.t loop i.e. [computable/variant/invariant]. Thanks On Fri, Dec 1, 2017 at

Chris Lattner wrote: > > int main() > > { > > int r(0); > > for (int i = 0; i < 100; ++i) > > r += i; > > ; > > return r; > > } > > When I compiled it, I got the following LLVM code: The code I get is somewhat different: int %main() { entry: %tmp.1.i = load bool* %Initialized.0__ ; <bool> [#uses=1] br