search for: zeroextend

...to create an expression for '%add' that it knows how to >> evaluate. >> >> The patch detects this pattern in createNodeForPHI and creates an >> equivalent expression that can be evaluated. >> >> Note that SCEV translates the 'and' into >> ZeroExtend(Truncate(%result.03, i8), i32) >> >> So in terms of SCEV expressions, we essentially have >> %add[n] = Add(ZeroExtend(Truncate(%add[n-1], i8), i32), 3) >> >> (BTW, I'm no scholar here, just a layman, so my terminology is >> probably all wrong). > Going...

...olution from > being able to create an expression for '%add' that it knows how to > evaluate. > > The patch detects this pattern in createNodeForPHI and creates an > equivalent expression that can be evaluated. > > Note that SCEV translates the 'and' into > ZeroExtend(Truncate(%result.03, i8), i32) > > So in terms of SCEV expressions, we essentially have > %add[n] = Add(ZeroExtend(Truncate(%add[n-1], i8), i32), 3) > > (BTW, I'm no scholar here, just a layman, so my terminology is > probably all wrong). Going with your LLVM IR testcase, t...

On Tue, Dec 18, 2012 at 9:56 AM, Matthew Curtis <mcurtis at codeaurora.org> wrote: > > Here's how I'm evaluating the expression (in my head): > > 00: Add(ZeroExtend(Truncate(Minus(AddRec(Start=0,Step=3)[n],3), i8), i32),3) > | > 01: Add(ZeroExtend(Truncate(Minus(AddRec(Start=0,Step=3)[0],3), i8), i32),3) > | > 02: Add(ZeroExtend(Truncate(Minus(3,3), i8), i32)...

...and' on line 8 prevents Scalar Evolution from being able to create an expression for '%add' that it knows how to evaluate. The patch detects this pattern in createNodeForPHI and creates an equivalent expression that can be evaluated. Note that SCEV translates the 'and' into ZeroExtend(Truncate(%result.03, i8), i32) So in terms of SCEV expressions, we essentially have %add[n] = Add(ZeroExtend(Truncate(%add[n-1], i8), i32), 3) (BTW, I'm no scholar here, just a layman, so my terminology is probably all wrong). The patch basically moves the ZeroExtend and Truncate outside...

...nfo ) and then select regions that answer some requirements ( > in ScopDetection ). Because only affine expressions in conditions and > bounds are permissible, we trying to get scalar expressions into > affine form by AffineSCEVIterator. At present there plugs for scev > types Truncate, ZeroExtend, SignExtend, UDivExpr, UMaxExpr , SMaxExpr. > Also there are no support for wrap flags NUW, NSW, NW. It can be > unsafe if we doesn't provide this information in polly IR. Yes, if AffineSCEVIterator can iterate Truncate, ZeroExtend and SignExtend correctly, polly can accept much more Scop...

...elect regions that answer some requirements ( >> in ScopDetection ). Because only affine expressions in conditions and >> bounds are permissible, we trying to get scalar expressions into >> affine form by AffineSCEVIterator. At present there plugs for scev >> types Truncate, ZeroExtend, SignExtend, UDivExpr, UMaxExpr , SMaxExpr. >> Also there are no support for wrap flags NUW, NSW, NW. It can be >> unsafe if we doesn't provide this information in polly IR. > Yes, if AffineSCEVIterator can iterate Truncate, ZeroExtend and > SignExtend correctly, polly can acc...

...in CFG ( by RegionInfo ) and then select regions that answer some requirements ( in ScopDetection ). Because only affine expressions in conditions and bounds are permissible, we trying to get scalar expressions into affine form by AffineSCEVIterator. At present there plugs for scev types Truncate, ZeroExtend, SignExtend, UDivExpr, UMaxExpr , SMaxExpr. Also there are no support for wrap flags NUW, NSW, NW. It can be unsafe if we doesn't provide this information in polly IR. So I will mainly improve AffineSCEVIterator. Now I should to show test cases indicating that - loops with above-listed types e...

...at answer some requirements ( >>> in ScopDetection ). Because only affine expressions in conditions and >>> bounds are permissible, we trying to get scalar expressions into >>> affine form by AffineSCEVIterator. At present there plugs for scev >>> types Truncate, ZeroExtend, SignExtend, UDivExpr, UMaxExpr , SMaxExpr. >>> Also there are no support for wrap flags NUW, NSW, NW. It can be >>> unsafe if we doesn't provide this information in polly IR. >> Yes, if AffineSCEVIterator can iterate Truncate, ZeroExtend and >> SignExtend correctl...

...eExpr((3 + (zext i8 {-3,+,3}<%for.body> to i32)), i8) 05: calls getTruncateExpr(3) 06: returns 3 07: calls getTruncateExpt((zext i8 {-3,+,3}<%for.body> to i32)) 08: returns {-3,+,3}<%for.body> 09: returns {0,+,3}<%for.body> 10: calls getZeroExtendExpr({0,+,3}<%for.body>, i32); 11: returns (zext i8 {0,+,3}<%for.body> to i32) 12: returns (zext i8 {0,+,3}<%for.body> to i32) This expression is (I believe) correct for %conv2. The intent of the patch is to construct the correct (evaluatable) expression for %result.03 b...

...equirements ( >>>> in ScopDetection ). Because only affine expressions in conditions and >>>> bounds are permissible, we trying to get scalar expressions into >>>> affine form by AffineSCEVIterator. At present there plugs for scev >>>> types Truncate, ZeroExtend, SignExtend, UDivExpr, UMaxExpr , SMaxExpr. >>>> Also there are no support for wrap flags NUW, NSW, NW. It can be >>>> unsafe if we doesn't provide this information in polly IR. >>> >>> Yes, if AffineSCEVIterator can iterate Truncate, ZeroExtend and &gt...

...tail call i32 @f(i8 zeroext 1) nounwind ; <i32> [#uses=1] ret i32 %0 } ----------- Finally calling it with: ---------- llvm-gcc -c -emit-llvm -O2 a.c lli -force-interpreter a.o ---------- Yields us: ----------- "Assertion failed: width > BitWidth && "Invalid APInt ZeroExtend request", file c:/proj/llvm/src/lib/Support/APInt.cpp, line 1064" ----------- where both width and BitWidth have value "32". Removing this assert in llvm source makes more similar (APInt related) asserts fail later. Is that a problem with llvm-gcc or is there a fix in llvm so...

...elect regions that answer some requirements ( >> in ScopDetection ). Because only affine expressions in conditions and >> bounds are permissible, we trying to get scalar expressions into >> affine form by AffineSCEVIterator. At present there plugs for scev >> types Truncate, ZeroExtend, SignExtend, UDivExpr, UMaxExpr , SMaxExpr. >> Also there are no support for wrap flags NUW, NSW, NW. It can be >> unsafe if we doesn't provide this information in polly IR. > Yes, if AffineSCEVIterator can iterate Truncate, ZeroExtend and > SignExtend correctly, polly can acc...

...gt; ret i32 %0 > } > ----------- > > > Finally calling it with: > ---------- > llvm-gcc -c -emit-llvm -O2 a.c > lli -force-interpreter a.o > ---------- > > Yields us: > ----------- > "Assertion failed: width> BitWidth&& "Invalid APInt ZeroExtend > request", file c:/proj/llvm/src/lib/Support/APInt.cpp, line 1064" > ----------- > where both width and BitWidth have value "32". > > > Removing this assert in llvm source makes more similar (APInt related) > asserts fail later. > > Is that a problem...

I cannot understand what does the paragraph mean. Could anyone please elaborate it? http://llvm.cs.uiuc.edu/ChrisLLVM/docs/CodeGenerator.html#selectiondag_legalize "Instead of using a Legalize pass, we could require that every target-specific selector supports and expands every operator and type even if they are not supported and may require many instructions to implement (in fact, this is

...t;> >> >> Finally calling it with: >> ---------- >> llvm-gcc -c -emit-llvm -O2 a.c >> lli -force-interpreter a.o >> ---------- >> >> Yields us: >> ----------- >> "Assertion failed: width>  BitWidth&&  "Invalid APInt ZeroExtend >> request", file c:/proj/llvm/src/lib/Support/APInt.cpp, line 1064" >> ----------- >> where both width and BitWidth have value "32". >> >> >> Removing this assert in llvm source makes more similar (APInt related) >> asserts fail later....

On 04/04/2011 12:23 AM, Vlad Krylov wrote: > > Hi. Hi Vlad, first of all it seems the conflict with raghesh was already solved. Nice. Regarding your draft. It looks like a reasonable first version, but it obviously needs to be extended for the final application. I would also recommend to install Polly and try to find the first test cases that cannot be handled. Some comments to your

Hi. My plan would be: 1w Study sources of Polly and LLVM docs relating to analysis. 2w Create tests which demonstrate problems with NSW/NUW 3-4w Fix the handling of wrap overflows. 5w Complete middle term paperwork. 6w Create tests for each of cases which are not currently optimized (e.g. have min/max, sext/zext, trunc or unsigned comparisons in the loop bounds or memory accesses). 7w Learn how

On Mon, Nov 5, 2012 at 5:17 PM, Eric Christopher <echristo at gmail.com> wrote: > For llvm-dwarfdump we need to handle relocations inside the debug info > sections in order to successfully dump the dwarf info including strings. > Nick sent out a partial patch that did this not too long ago and I've taken > it and gone in a bit of a different direction, but kept the same basic

For llvm-dwarfdump we need to handle relocations inside the debug info sections in order to successfully dump the dwarf info including strings. Nick sent out a partial patch that did this not too long ago and I've taken it and gone in a bit of a different direction, but kept the same basic architecture. In place of applying the relocations to the data we've read from disk I'm keeping

Hi all, > On 2 Oct 2019, at 14:34, Sanjay Patel <spatel at rotateright.com> wrote > Providing target options/overrides to code that is supposed to be target-independent sounds self-defeating to me. I doubt that proposal would gain much support. > Of course, if you're customizing LLVM for your own out-of-trunk backend, you can do anything you'd like if you're willing to