similar to: [LLVMdev] Cast to SCEVAddRecExpr

Displaying 20 results from an estimated 1000 matches similar to: "[LLVMdev] Cast to SCEVAddRecExpr"

2015 Mar 19
2
[LLVMdev] Cast to SCEVAddRecExpr
Hi Nick, Thanks for looking into it. I have tried that as well but it didn't worked. "AddExpr->getOperand(0))" node is: " (4 * (sext i32 {2,+,2}<%for.body4> to i64))<nsw>" When I cast this to "SCEVAddRecExpr" it returns NULL. Regards, Ashutosh -----Original Message----- From: Nick Lewycky [mailto:nicholas at mxc.ca] Sent: Thursday, March 19,
2015 Mar 19
3
[LLVMdev] Cast to SCEVAddRecExpr
Yes, I can get "SCEVAddRecExpr" from operands of "(sext i32 {2,+,2}<%for.body4> to i64)". So whenever SCEV cast to "SCEVAddRecExpr" fails, we have drill down for such patterns ? Is that the right way ? Regards, Ashutosh -----Original Message----- From: Nick Lewycky [mailto:nicholas at mxc.ca] Sent: Thursday, March 19, 2015 1:02 PM To: Nema, Ashutosh Cc:
2015 Mar 31
2
[LLVMdev] Cast to SCEVAddRecExpr
Sorry typo in test case, Please ignore previous mail. Consider below case: for (j=1; j < itr; j++) { - - - - for (i=1; i < itr; i++) { { temp= var[i << 1]; - - - - - } } In the above example, we are unable to get "SCEVAddRecExpr" for "var[i << 1]" Its "SCEVAddRecExpr" is computable in *Outer Loop* I
2015 Apr 01
2
[LLVMdev] Cast to SCEVAddRecExpr
Thanks Sanjoy. > To be pedantic, "var[i<<1]" is not an add recurrence, but "&var[i << > 1]" is an add recurrence. I'll assume that's that you meant. Yes, I meant the same. > I think that is because in C, multiplication is nsw but left shift is > not and so "i << 1" can legitimately sign-overflow but i * 2 cannot >
2014 Apr 01
2
[LLVMdev] Construction of SCEVAddRecExpr
Hello, I'm studying how the SCEV analyzis works and how to use it and I could not create an example where the SCEV analyzis identifies an expression as "SCEVAddRecExpr". Aren't the expressions below the kind of pattern that should be represented as a "AddRecExpr" ? SCEV: (1 + (2 * %3) or SCEV: (%1 + (2 * %3) or SCEV: (%1 + (%2 * %3) In my experiments they are
2015 Mar 24
3
[LLVMdev] RFC: Loop versioning for LICM
> On Mar 20, 2015, at 8:02 PM, Nema, Ashutosh <Ashutosh.Nema at amd.com> wrote: > > > Yes, this is what I was proposing above and here ;): > Thanks Adam it’s for confirming J NP :). > > > No, not hasLoopInvariantStore but hasAccessToLoopInvariantAddress. > Its only for invariant stores[not loads], Using ‘hasLoopInvariantStore’ (or a name with invariant store)
2012 Apr 25
2
[LLVMdev] About Scalar Evolution Pass and SCEVAddRecExpr
Hi, I wonder how many of you are familiar with scalar evolution pass. I met a problem regarding to the SCEVAddRecExpr. Say for the code: const int N = 100; int a[N]; for(int i=0;i<N;i++) a[i] = 0; For the access of a[i], the pass will transform this a[i] to a SCEVAddRecExpr <@a, +, sizeof(int)><BB_Name>, which means the access of the array `a' starts from the address `a' and
2012 Apr 25
0
[LLVMdev] About Scalar Evolution Pass and SCEVAddRecExpr
Hi, You may try function "getSCEVAtScope" of the ScalarEvolution analysis: /// getSCEVAtScope - Return a SCEV expression for the specified value /// at the specified scope in the program. The L value specifies a loop /// nest to evaluate the expression at, where null is the top-level or a /// specified loop is immediately inside of the loop. /// /// This method can be used to compute
2015 Mar 20
2
[LLVMdev] RFC: Loop versioning for LICM
> On Mar 19, 2015, at 9:46 PM, Nema, Ashutosh <Ashutosh.Nema at amd.com> wrote: > > Thanks Adam for your reply. > > From: Adam Nemet [mailto:anemet at apple.com <mailto:anemet at apple.com>] > Sent: Friday, March 20, 2015 3:23 AM > To: Nema, Ashutosh > Cc: Hal Finkel; Philip Reames; llvmdev at cs.uiuc.edu <mailto:llvmdev at cs.uiuc.edu> > Subject:
2016 May 16
6
Working on FP SCEV Analysis
[+CC Andy] Hi Elena, I don't have any fundamental issues with teaching SCEV about floating point types, but given this will be a major change, I think a high level roadmap should be discussed on llvm-dev before we start reviewing and committing changes. Here are some issues that I think are worth discussing: - Core motivation: why do we even care about optimizing floating point
2011 May 07
1
[LLVMdev] Loop transformations using LLVM
On May 5, 2011, at 5:11 AM, Rotem, Nadav wrote: > Malveeka, > > You can use the LoopInfo analysis to find the induction variable. > > http://llvm.org/docs/doxygen/html/classllvm_1_1Loop.html#a72bbf45d2e00971f56bf8cfe4e1df01c > > Cheers, > Nadav getCanonicalInductionVariable is a good example of finding IVs without iterating over instructions. But you may need to
2011 Nov 14
1
[LLVMdev] How to make Polly ignore some non-affine memory accesses
On 11/14/2011 01:24 AM, Marcello Maggioni wrote: > Hi Tobias. > > I worked on enabling Polly accepting non affine memory accesses and I > produced a patch. Great. > I saw that there were a lot of updates in Polly recently, so I had to > redo a lot of the work I did and that slowed me quite a bit. Ups, sorry! However, I believe without these changes detecting non-affine memory
2011 Nov 02
5
[LLVMdev] How to make Polly ignore some non-affine memory accesses
Mmm I found out a very strange behavior (to me) of the SCEV analysis of the loop bound of the external loop I posted. When in ScopDetection it gets the SCEV of the external loop bound in the "isValidLoop()" function with: const SCEV *LoopCount = SE->getBackedgeTakenCount(L); It returns a SCEVCouldNotCompute, but if I change the "if" block inside the loop from: if
2015 Jun 10
3
[LLVMdev] Question about NoWrap flag for SCEVAddRecExpr
I am testing vectorization on the following test case: float x[1024], y[1024]; void myloop1() { for (long int k = 0; k < 512; k++) { x[2*k] = x[2*k]+y[k]; } } Vectorization failed due to "unsafe dependent memory operation". I traced the LoopAccessAnalysis.cpp and found the reason is the NoWrapFlag for SCEVAddRecExpr is not set and consequently the
2016 Oct 04
2
Getting the symbolic expression for an address calculation
How do you generate a SCEVAddRecExpr from a SCEV? It tried dyn_casting and it seems like that the SCEV returned by getSCEV is not a SCEVAddRecExpr. Thanks On Fri, Sep 30, 2016 at 4:16 PM, Friedman, Eli <efriedma at codeaurora.org> wrote: > On 9/30/2016 12:16 PM, Charith Mendis via llvm-dev wrote: > >> >> Hi all, >> >> What is the best way to get the symbolic
2016 Jan 20
2
Why getFunction() of CallGraphNode return NULL function?
So, I won't know the called function statically, Right? -------------------------------------------- Qiuping Yi Institute Of Software Chinese Academy of Sciences On Wed, Jan 20, 2016 at 2:24 PM, Nema, Ashutosh <Ashutosh.Nema at amd.com> wrote: > Typically for C++ virtual function you will see an indirect callSite > (unless not de-virtualized). > > > > Regards, >
2016 Apr 12
2
X86 TRUNCATE cost for AVX & AVX2 mode
<Copied Cong> Thanks Elena. Mostly I was interested in why such a high cost 30 kept for TRUNCATE v16i32 to v16i8 in SSE41. Looking at the code it appears like TRUNCATE v16i32 to v16i8 in SSE41 is very expensive vs SSE2. I feel this number should be same/close to the cost mentioned for same operation in SSE2ConversionTbl. Below patch from Cong Hou reduce cost for same operation in SSE2
2017 Mar 14
10
[Proposal][RFC] Epilog loop vectorization
Summarizing the discussion on the implementation approaches. Discussed about two approaches, first running ‘InnerLoopVectorizer’ again on the epilog loop immediately after vectorizing the original loop within the same vectorization pass, the second approach where re-running vectorization pass and limiting vectorization factor of epilog loop by metadata. <Approach-2> Challenges with
2016 Feb 25
2
how to force llvm generate gather intrinsic
It seems that http://reviews.llvm.org/D15690 only implemented gather/scatter for AVX-512, but not for AVX/AVX2. Is there any plan to enable gather for AVX/2? Thanks. Best, Zhi On Thu, Feb 25, 2016 at 8:28 AM, Sanjay Patel <spatel at rotateright.com> wrote: > I don't think gather has been enabled for AVX2 as of r261875. > Masked load/store were enabled for AVX with: >
2015 Mar 19
2
[LLVMdev] RFC: Loop versioning for LICM
Hi Ashutosh, > On Mar 16, 2015, at 9:06 PM, Nema, Ashutosh <Ashutosh.Nema at amd.com> wrote: > > Hi Adam, > > From: Adam Nemet [mailto:anemet at apple.com <mailto:anemet at apple.com>] > Sent: Wednesday, March 11, 2015 10:48 AM > To: Nema, Ashutosh > Cc: llvmdev at cs.uiuc.edu <mailto:llvmdev at cs.uiuc.edu> > Subject: Re: [LLVMdev] RFC: Loop