similar to: [LLVMdev] Question on Loop Normalization in LLVM

Hi all, It looks like the induction variable simplification pass prefers doing a zero-extension to compute the wider trip count of loops when extending the IV. This can sometimes result in loss of information making ScalarEvolution's analysis conservative which can lead to missed performance opportunities. For example, consider this loopnest- int i, j; for(i=0; i< 40; i++) for(j=0;

Hi Preston, On Fri, May 4, 2012 at 9:12 AM, Preston Briggs <preston.briggs at gmail.com> wrote: > > which produces > > %arrayidx24 = getelementptr inbounds [100 x [100 x i64]]* %A, i64 > %arrayidx21.sum, i64 %add1411, i64 %add > store i64 0, i64* %arrayidx24, align 8 > {{{(5 + ((3 + %n) * %n)),+,(2 * %n * %n)}<%for.cond1.preheader>,+,(4 *

Hi All, I was debugging a clang binary when i found this problem. The following code is complied with clang. typedef struct s { short s; } SVAL; void recurse (SVAL a, int depth) { a.s = --depth; if (depth == 0) return; else recurse(a,depth); } int main () { SVAL s; s.s = 5; recurse (s, 5); return 0; } When i try to access value of a.s in function recurse through gdb(i.e

Hi All, I'm trying to understand BB Vectorizer and gone through http://llvm.org/devmtg/2012-04-12/Slides/Hal_Finkel.pdf Wanted to know how to use bb-vectorize-debug-candidate-selection and bb-vectorize-debug-pair-selection command arguments. I tried the command with debug build clang - clang -O2 test.c -mllvm -vectorize \ -mllvm -debug-only=bb-vectorize \ -mllvm

Renato, can you post a hand-created vectorized IR of how a reduction would work on your example? I don’t think that recognizing this as a reduction is going to get you far. A reduction is beneficial if the value reduced is only truly needed outside of a loop. This is not the case here (we are storing/loading from the pointer). Your example is something like WRITEPTR = phi i8* [ outsideval,

Is there any chance of replacing/extending the GEP instruction? As noted in the GEP FAQ, GEPs don't support variable-length arrays; when the front ends have to support VLAs, they linearize the subscript expressions, throwing away information. The FAQ suggests that folks interested in writing an analysis that understands array indices (I'm thinking of dependence analysis) should be

Hi Nadav, Arnold, I managed to find some time to work on the pointer reduction, and I got a patch that can make "canVectorize()" pass. Basically what I do is to teach AddReductionVar() about pointers, saying they don't really have an exit instructions, and that (maybe) the final store is a good candidate (is it?). This makes it recognize the writes and reads, but then

Hi David, I think it might not be exactly PR13303 which might be causing the corruption of struct when accessed through GDB. This seems to be an ABI problem in clang. The problem seems to be that when we have pass by value of struct (having indirect arguments) stack is not aligned properly. I tried realigning the stack for indirect arguments in(TargetInfo.cpp) - ABIArgInfo

----- Original Message ----- > > > > On Jun 24, 2013, at 4:24 PM, Hal Finkel < hfinkel at anl.gov > wrote: > > > > > Indvars should ideally preserve NSW flags whenever possible. However, > we don't want to rely on SCEV to preserve them. SCEV expressions are > implicitly reassociated and uniqued in a flow-insensitive universe > independent of the

Hi Ayal, Let me start with commenting on this: > A dedicated intrinsic that freezes the compare instruction, for no apparent reason, may potentially cripple subsequent passes from further optimizing the vectorized loop. The point is we have a very good reason, which is that it passes on the right information on the backend, enabling opimisations as opposed to crippling them. The compare

Hello, Recently I've come across two instances where Induction Variable Simplification lead to noticable performance regressions. In one case, the removal of extra IV lead to the inability to reschedule instructions in a tight loop to reduce stalls. In that case, there were enough registers to spare, so using extra register for extra induction variable was preferable since it reduced

Hi Relph, I'm trying to print the value of 'a' while executing a.s = --depth; I have used break line number instead of break function so that the initial prologue part gets executed. The problem seems to be happening when parameters are pushed into stack and we call a function recursively. For example in the code when we have a int s; inside the struct instead of short s; gdb is able

> The compare of interest is clear, I think. It compares a Vector Induction Variable with a broadcasted loop invariant value, aka the BTC. Obtaining the latter operand is the goal, clearly, but to do so, the former operand needs to be recognized as a VIV. Yep, exactly that. > What if this compare is not generated by LV’s fold-tail-by-masking transformation? Not sure I completely follow

I am attempting to implement a minor loop strength reduction optimization for targets that support compare and jump fusion, specifically TTI::canMacroFuseCmp(). My approach might be wrong; however, I am soliciting the idea for feedback, so that I can implement this correctly. My plan is to add a Supplemental LSR formula to LoopStrengthReduce.cpp that optimizes the following case, but perhaps

Hello all, I wanted to get some feedback on this patch for ScalarEvolution. It addresses a performance problem I am seeing for simple benchmark. Starting with this C code: 01: signed char foo(void) 02: { 03: const int count = 8000; 04: signed char result = 0; 05: int j; 06: 07: for (j = 0; j < count; ++j) { 08: result += (result_t)(3); 09: } 10: 11: return result; 12: } I

Hi Tobi, I would like to remove the SCEVRewriter code and replace it with a call to SCEVAddRec::apply (see attached a patch that adds just this function). More precisely I want to add another function called apply_map that applies a map (loop -> expr) on a given scev. This is the apply function on a multi-variate polynomial. So here is an overview of how I would like the scev code generator

For reference, the case with a variable loop count is filed as PR27894: https://llvm.org/bugs/show_bug.cgi?id=27894 And the case with a constant loop count is filed as PR27899: https://llvm.org/bugs/show_bug.cgi?id=27899 On Thu, Jun 2, 2016 at 7:48 AM, Demikhovsky, Elena via llvm-dev < llvm-dev at lists.llvm.org> wrote: > I implemented IV simplification with FP SCEV and uploaded a new

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

To the best of my experience, handling case B (secondary induction) is must-have, and if I’m not mistaken, people aren’t opposed to that. For me, handling case A (primary induction) is “why not?”, but I certainly admit that that can be very naïve thinking coming from lack of good understanding on SCEV and their proper usages. Now, let’s assume we can postpone discussion about case A. What is the

I would like to nominate Sanjoy Das as code owner of Scalar Evolution and Induction Variable Simplification. Scalar Evolution has never had an official code owner, but does regularly need in depth review. Over the past year and a half, Sanjoy has made fantastic contributions to SCEV and has been responsive reviewing patches. He is clearly the authority at this point. Induction variable