search for: scalarrepl

...lo, LLVMdev. >> >> The problem is that C backend doesn't support integers wider than 64 >> bits, but I need to use it on programs with wide integers in LLVM IR. My >> question is how to deny LLVM to generate wide integer? Which part of >> LLVM should I modify? > scalarrepl is the only pass I can think of off the top of my head that > does that normally (although there might be others); you can either > avoid it (in favor of the simpler mem2reg), or hack it up so it > doesn't do that. > > -Eli scalarrepl didn't help. Command "opt -scalarrep...

...: >>> The problem is that C backend doesn't support integers wider than 64 >>> bits, but I need to use it on programs with wide integers in LLVM IR. My >>> question is how to deny LLVM to generate wide integer? Which part of >>> LLVM should I modify? >> scalarrepl is the only pass I can think of off the top of my head that >> does that normally (although there might be others); you can either >> avoid it (in favor of the simpler mem2reg), or hack it up so it >> doesn't do that. >> > scalarrepl didn't help. Command "opt...

Hi Chris, Thanks for your reply. You said that scalarRepl gets shy about loads and stores of the entire aggregate. Then I use a test case: ; ModuleID = 'test1.ll' define i32 @fun(i32* nocapture %X, i32 %i) nounwind uwtable readonly { %stackArray = alloca <4 x i32> %XC = bitcast i32* %X to <4 x i32>* %arrayVal = load <4 x i32&...

Hi all, I want to use scalarrepl pass to eliminate the allocation of mat_alloc which is of type [4 x <4 x float>] in the following program. $cat test.ll ; ModuleID = 'test.ll' define void @main(<4 x float>* %inArg, <4 x float>* %outArg, [4 x <4 x float>]* %constants) nounwind { entry: %inArg1 =...

On Mar 10, 2012, at 9:34 AM, Fan Dawei wrote: > Hi all, > > I want to use scalarrepl pass to eliminate the allocation of mat_alloc which is of type [4 x <4 x float>] in the following program. > > $cat test.ll > > ; ModuleID = 'test.ll' > > define void @main(<4 x float>* %inArg, <4 x float>* %outArg, [4 x <4 x float>]* %constants...

Hi Fan, > You said that scalarRepl gets shy about loads and stores of the entire > aggregate. Then I use a test case: > > ; ModuleID = 'test1.ll' > define i32 @fun(i32* nocapture %X, i32 %i) nounwind uwtable readonly { > %stackArray = alloca <4 x i32> > %XC = bitcast i32* %X to <4 x i32>*...

...ndividual scalars, which are allocated to the target machine's physical registers as much as possible. But that turns out not to be the case and I end up with code which constantly reads and writes memory to access my virtual registers. The "Scalar Replacement of Aggregates" pass (scalarrepl) seems to be capable of splitting structures into separate fields so that mem2reg can produce efficient code which avoids redundant memory operations. But it skips my array entirely. Here's a small piece of C code which illustrates the problem: int foo(int x, int y) { int r[2]; r...

...ich are allocated > to the target machine's physical registers as much as possible. But that > turns out not to be the case and I end up with code which constantly > reads and writes memory to access my virtual registers. > > The "Scalar Replacement of Aggregates" pass (scalarrepl) seems to be > capable of splitting structures into separate fields so that mem2reg can > produce efficient code which avoids redundant memory operations. But it > skips my array entirely. Here's a small piece of C code which > illustrates the problem: > > int foo(int x, int y...

...39;s static/dynamic features. > However I couldn't glean much information from this data as almost in > all cases there is no change in the runtime when compared to O0 except > for few programs where gvn and loop-rotate improved the program > performance to some extent. But the 'scalarrepl' optimization is an > exception because it almost consistently improved the program > performance and in fact it almost matches the O3 level performance of > the program. > > Can some one enlighten about what is happening? Is there any thing > wrong in my experimental setup?...

...responding program's static/dynamic features. However I couldn't glean much information from this data as almost in all cases there is no change in the runtime when compared to O0 except for few programs where gvn and loop-rotate improved the program performance to some extent. But the 'scalarrepl' optimization is an exception because it almost consistently improved the program performance and in fact it almost matches the O3 level performance of the program. Can some one enlighten about what is happening? Is there any thing wrong in my experimental setup? Thank you -Suresh

Hello, LLVMdev. The problem is that C backend doesn't support integers wider than 64 bits, but I need to use it on programs with wide integers in LLVM IR. My question is how to deny LLVM to generate wide integer? Which part of LLVM should I modify? Best regards, V. Korchagin.

....com> wrote: > Hello, LLVMdev. > > The problem is that C backend doesn't support integers wider than 64 > bits, but I need to use it on programs with wide integers in LLVM IR. My > question is how to deny LLVM to generate wide integer? Which part of > LLVM should I modify? scalarrepl is the only pass I can think of off the top of my head that does that normally (although there might be others); you can either avoid it (in favor of the simpler mem2reg), or hack it up so it doesn't do that. -Eli

...e hard to extend mem2reg to also consider elements > of arrays for promotion? It should obviously not perform the promotion > when in between the store and load there's a dynamically indexed > access to the array. Correct me if I'm wrong, but that seems it would > be superior to scalarrepl itself (for arrays). > > Is there anyone experienced with mem2reg who wants to implement this? > If not, any advice on how to best approach this? Classically, we use dependence analysis to support such optimizations. For example, see Chapter 8 in Allen & Kennedy's book, "Opti...

On Sep 13, 2008, at 1:07 PM, Matthijs Kooijman wrote: > Hi Dan, > >> Changing PromoteCastOfAllocation to not replace aggregate allocas >> with >> non-aggregate allocas if they have GEP users sounds reasonable to me. > This sounds reasonable indeed, but still a bit arbitrary. Haven't > figured out > anything better yet, though. > >> Finding the

...ns you can remove a single (or perhaps a few) bitcasts, while introducing a bunch of other bitcasts. IMHO, a better policy is needed. Another problem that occurs here, is that this transformation can replace a struct alloca with a single integer alloca. This, in turn, can confuse other passes like scalarrepl, and produce but ugly code. I've assembled a small example of this. declare void @bar(i16, i16) define internal void @empty(i32* %X) { ret void } define void @foo(i16 %A, i16 %B) { entry: ;; Alloc a struct %V = alloca {i16, i16} ;; Save our arguments into it %V1 = getelementpt...

In svn r95224 I modified the scalar replacement (SROA) pass to use different criteria to decide when it is likely to be profitable to split up an aggregate into its separate elements. The commit message has a pretty decent explanation, but I wanted to give some further detail here. I am hoping that the llvm-dev list allows messages with attachments. If the graphs get stripped off, this

Hi Dan, > Changing PromoteCastOfAllocation to not replace aggregate allocas with > non-aggregate allocas if they have GEP users sounds reasonable to me. This sounds reasonable indeed, but still a bit arbitrary. Haven't figured out anything better yet, though. > Finding the maximum alignment is sometimes still useful though, so > it would be nice to update the alignment field of

...his is caused by llvm-gcc, not instcombine. Related to this issue, I've created two more patches. I'm including them here for review, comments are welcome. I'm not sure if these patches actually make a lot of difference in real world applications and they are not yet sufficient to make scalarrepl do its work completely in our example code (lots of struct passing and the resulting memmoves), but they will at least make the resulting code more logical and make it possible to get there. I've tested these patches against the dejagnu tests and the test-suite, finding only two failures. The...

...like to know which optimization passes are performed at -O2 by opt. So I used following command: llvm-as < /dev/null | opt -O2 -std-compile-opts -disable-output -debug-pass=Arguments I've got following output for LLVM opt 2.9: Pass Arguments: -no-aa -tbaa -basicaa -simplifycfg -domtree -scalarrepl -early-cse Pass Arguments: -targetlibinfo -no-aa -tbaa -basicaa -preverify -domtree -verify -lowersetjmp -globalopt -ipsccp -deadargelim -instcombine -simplifycfg -basiccg -prune-eh -inline -functionattrs -argpromotion -scalarrepl-ssa -domtree -early-cse -simplify-libcalls -lazy-value-info -jump-t...

...n how distinguish such loops, I tried to disable loop-rotate. For this purpose, I got the list of passes executed by O3, I eliminate loop-rotate and I call the reduced list of passes from opt: opt -targetdata -no-aa -tbaa -targetlibinfo -basicaa -preverify -domtree -verify -simplifycfg -domtree -scalarrepl -early-cse -lower-expect -targetlibinfo -targetdata -no-aa -tbaa -basicaa -globalopt -ipsccp -deadargelim -instcombine -simplifycfg -basiccg -prune-eh -inline -functionattrs -argpromotion -scalarrepl-ssa -domtree -early-cse -simplify-libcalls -lazy-value-info -jump-threading -correlated-propagation...