search for: createscev

...07: %result.03 = phi i32 [ 0, %entry ], [ %add, %for.body ] 08: %conv2 = and i32 %result.03, 255 09: %add = add nsw i32 %conv2, 3 10: %inc = add nsw i32 %j.04, 1 11: %cmp = icmp slt i32 %inc, 8000 12: br i1 %cmp, label %for.body, label %for.end LLVM executes the following: 01: createSCEV(%conv2 = and i32 %result.03, 255) 02: calls getSCEV(%result.03) 03: returns (3 + (zext i8 {-3,+,3}<%for.body> to i32)) 04: calls getTruncateExpr((3 + (zext i8 {-3,+,3}<%for.body> to i32)), i8) 05: calls getTruncateExpr(3) 06: returns 3 07: calls getTrunc...

...[ %add, %for.body ] > 08: %conv2 = and i32 %result.03, 255 > 09: %add = add nsw i32 %conv2, 3 > 10: %inc = add nsw i32 %j.04, 1 > 11: %cmp = icmp slt i32 %inc, 8000 > 12: br i1 %cmp, label %for.body, label %for.end > > LLVM executes the following: > > 01: createSCEV(%conv2 = and i32 %result.03, 255) > 02: calls getSCEV(%result.03) > 03: returns (3 + (zext i8 {-3,+,3}<%for.body> to i32)) The problem is that this is not a correct expression for %result.03. It isn't safe to use incorrect expressions in ScalarEvolution even if it happens...

Good evening, Pierre. Here is an example to you. attached. run with -disable-lazy-comilation. It is *as-is* for Win32 but might be applicable to *-linux-elf more smartly. It does get llvm::Function* by function ptr(not name!), and clone a specialized function, and execute specialized one in the same context as parent lli. > - In a running program, can I get pointers to the llvm Module that

...nsert(V, getUnknown(V)); >> Can this be assert(!PessimisticMode && !PendingCache.empty()) since on a "top call" we could not have hit self recursion yet? Yes, if we reset them before exiting 'IsTopCall'. I wasn't doing that :) > } > > SCEV *S = createSCEV(); > > If(IsTopCall) { > FinalCache.insert(V, S); > forgetMemoizedResults(PendingCache); >> I'm not 100% sure, but I suspect this will not work. >> forgetMemoizedResults will only remove the Value->SCEV mapping for the conservative cases, but in the test ca...

Hello ! I wanted to experiment with partial evaluation and llvm seems to be the right tool for this, but since I'm new to it of course I'm a bit lost ! I'll try to explain what I want to do in the simplest possible way : I have a C program. In this program, there is a function f( a,b ). I have a value A for a. I want to specialise f() so I get a function fA( b ) which is the same as

...f I can, why isn't the SCEV package simplifying things for me? The short answer is that SCEV is terrible at preserving NSW flags. I personally don't believe they belong in SCEV but the merits of making any design change here are dubious. To understand one example of SCEV dropping NSW, see createSCEV for Instruction::Add. Synopsis: your add is not a "basic induction variable" so its NSW flag does not bound the number of loop iterations. We only know that the add's original IR users expect NSW. There could be other IR adds with the same expression, but without the NSW flag. SCEV do...

...; Can this be assert(!PessimisticMode && !PendingCache.empty()) since on a "top call" we could not have hit self recursion yet? > > > Yes, if we reset them before exiting 'IsTopCall'. I wasn't doing that :) > > >> } >> >> SCEV *S = createSCEV(); >> >> If(IsTopCall) { >> FinalCache.insert(V, S); >> forgetMemoizedResults(PendingCache); > >>> I'm not 100% sure, but I suspect this will not work. >>> forgetMemoizedResults will only remove the Value->SCEV mapping for the conservati...

Given the following SCEV, *(sext i32 {2,+,1}<nw><%for.body> to i64)* from the following C source, *void strong3(int *A, int *B, int n) {* * for (int i = 0; i < n; i++) {* * A[i + 2] = i;* * ...* * }* *}* Since the No-Wrap flag is set on the addrec, can't I safely rewrite it as *{2,+,1}<nw><%for.body>* If I can, why isn't the SCEV package

...the problem is the (4 * %k) 'Index' expression, which lacks the no-wrap flags, and when createNodeForGEP uses it to construct the overall expression for the address, the result also lacks the nsw flag. The reason that the (4 * %k) 'Index' expression lacks the flags is explained in createSCEV: // Don't apply this instruction's NSW or NUW flags to the new // expression. The instruction may be guarded by control flow that the // no-wrap behavior depends on. Non-control-equivalent instructions can be // mapped to the same SCEV expression, and it would be incorrect...

...e); } ScalarEvolution::getSCEVImpl (Value *V, bool IsTopCall = false) { // Look up in cache using logic described above If (S = getExistingSCEV()) return S; if (IsTopCall) { PessimisticMode = false; PendingCache.clear(); PendingCache.insert(V, getUnknown(V)); } SCEV *S = createSCEV(); If(IsTopCall) { FinalCache.insert(V, S); forgetMemoizedResults(PendingCache); } else if (PessimisticMode) { PendingCache.insert(V, S); } else { FinalCache.insert(V, S); } return S; } Implementation in ScalarEvolution.cpp uses getSCEVImpl() instead of getSCEV(). Th...

...sTopCall) { > PessimisticMode = false; > PendingCache.clear(); > PendingCache.insert(V, getUnknown(V)); Can this be assert(!PessimisticMode && !PendingCache.empty()) since on a "top call" we could not have hit self recursion yet? > } > > SCEV *S = createSCEV(); > > If(IsTopCall) { > FinalCache.insert(V, S); > forgetMemoizedResults(PendingCache); I'm not 100% sure, but I suspect this will not work. forgetMemoizedResults will only remove the Value->SCEV mapping for the conservative cases, but in the test case you attached ge...

...ackage simplifying things for me? > > > The short answer is that SCEV is terrible at preserving NSW flags. I > personally don't believe they belong in SCEV but the merits of making any > design change here are dubious. > > To understand one example of SCEV dropping NSW, see createSCEV for > Instruction::Add. Synopsis: your add is not a "basic induction variable" so > its NSW flag does not bound the number of loop iterations. We only know > that the add's original IR users expect NSW. There could be other IR adds > with the same expression, but without t...

...nsert(V, getUnknown(V)); >> Can this be assert(!PessimisticMode && !PendingCache.empty()) since on a "top call" we could not have hit self recursion yet? Yes, if we reset them before exiting 'IsTopCall'. I wasn't doing that :) > } > > SCEV *S = createSCEV(); > > If(IsTopCall) { > FinalCache.insert(V, S); > forgetMemoizedResults(PendingCache); >> I'm not 100% sure, but I suspect this will not work. >> forgetMemoizedResults will only remove the Value->SCEV mapping for the conservative cases, but in the test ca...

Note that there is a slight difficulty due to the fact that we "sink" the trunc: (zext i16 {0,+,1}<%bb> to i32) + (65536 * ({0,+,1}<nuw><%bb> /u 65536) Here the recurrence lost it's <nuw> and got reduced to a i16 (on the left), but not on the right. But we can prove: - that (zext i16 {0,+,1}<%bb> to i32) has the same 16 LSB than (i32

...; Can this be assert(!PessimisticMode && !PendingCache.empty()) since on a "top call" we could not have hit self recursion yet? > > > Yes, if we reset them before exiting 'IsTopCall'. I wasn't doing that :) > > >> } >> >> SCEV *S = createSCEV(); >> >> If(IsTopCall) { >> FinalCache.insert(V, S); >> forgetMemoizedResults(PendingCache); > >>> I'm not 100% sure, but I suspect this will not work. >>> forgetMemoizedResults will only remove the Value->SCEV mapping for the conservati...

...-exponential in the size of the DAG. If you just have a very large tree with many similar looking subexpressions, then I'm not sure what to do except cut it into reasonable subtrees. AFAICT, it's not just sorting that's a problem but also grouping? Also, I think the shear depth of the createSCEV recursion is itself a problem. I don't see any reason not to limit the size of SCEV expressions, but I also don't have a brilliant idea for how to do it at the moment (other than the obvious depth cutoff). -Andy -------------- next part -------------- An HTML attachment was scrubbed... URL...

...em is the (4 * %k) 'Index' expression, which lacks the no-wrap flags, and when createNodeForGEP uses it to construct the overall expression for the address, the result also lacks the nsw flag. > > The reason that the (4 * %k) 'Index' expression lacks the flags is explained in createSCEV: > > // Don't apply this instruction's NSW or NUW flags to the new > // expression. The instruction may be guarded by control flow that the > // no-wrap behavior depends on. Non-control-equivalent instructions can be > // mapped to the same SCEV expression, and i...

...cMode && !PendingCache.empty()) since on a "top call" we could not have hit self recursion yet? >> >> >> Yes, if we reset them before exiting 'IsTopCall'. I wasn't doing that :) >> >> >>> } >>> >>> SCEV *S = createSCEV(); >>> >>> If(IsTopCall) { >>> FinalCache.insert(V, S); >>> forgetMemoizedResults(PendingCache); >> >>>> I'm not 100% sure, but I suspect this will not work. >>>> forgetMemoizedResults will only remove the Value->SCE...

...ctly trees--exponential in the size of the DAG. If you just have a very large tree with many similar looking subexpressions, then I’m not sure what to do except cut it into reasonable subtrees. AFAICT, it’s not just sorting that’s a problem but also grouping? Also, I think the shear depth of the createSCEV recursion is itself a problem. I don’t see any reason not to limit the size of SCEV expressions, but I also don’t have a brilliant idea for how to do it at the moment (other than the obvious depth cutoff). -Andy -------------- next part -------------- An HTML attachment was scrubbed... URL: <ht...

...;t the SCEV package simplifying things for me? > > The short answer is that SCEV is terrible at preserving NSW flags. I personally don't believe they belong in SCEV but the merits of making any design change here are dubious. > > To understand one example of SCEV dropping NSW, see createSCEV for Instruction::Add. Synopsis: your add is not a "basic induction variable" so its NSW flag does not bound the number of loop iterations. We only know that the add's original IR users expect NSW. There could be other IR adds with the same expression, but without the NSW flag. SCEV do...