similar to: [LLVMdev] Overzealous PromoteCastOfAllocation

Hi Matthijs, Changing PromoteCastOfAllocation to not replace aggregate allocas with non-aggregate allocas if they have GEP users sounds reasonable to me. Finding the maximum alignment is sometimes still useful though, so it would be nice to update the alignment field of the alloca even if its type is left unchanged. Dan On Sep 8, 2008, at 8:57 AM, Matthijs Kooijman wrote: > Hi all, >

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

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

Hi Dan, > Oh, ok. So code that takes an alloca, bitcasts the address to a higher > alignment, Since alignment is not a property of a type, I don't think you can "bitcast to a higher alignment" as such. I still understand what you mean, though :-) > and then does a load or store at the higher alignment, is > invoking undefined behavior. The alignment attribute on a load

On Sep 23, 2008, at 4:16 AM, Matthijs Kooijman wrote: > >> and then does a load or store at the higher alignment, is >> invoking undefined behavior. The alignment attribute on a load or >> store >> is an assertion about the actual alignment of the memory. > Should this undefined behaviour be caught by the verifier, or is it > ok for it > to exist? I

On Jan 2, 2012, at 10:00 AM, Duncan Sands <baldrick at free.fr> wrote: > Hi Matt, > >> It seems that one of the optimization passes (it seems to be SROA) sometimes transforms computations on vectors of ints to computations on wide integer types; for example, I'm seeing code like the following after optimizations(*): >> >> %0 = bitcast<16 x i8>

Hello, I am trying to simplify the CFG of a given code and eliminate the conditionals, even though I will obtain codes that are not semantically equivalent. For example, given a simple loop: for(i=0; i<N; i++){    a[i] = i;     if (i%2==0)       a[i] += 12; } I would keep only the loop, without the if statement: for(i=0; i<N; i++){    a[i] = i; } I can eliminate such conditionals on

Hi all, I would 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

Hi all, I have a question regarding dynamic indexing into a vector with GEP. I see that in the ScalarReplAggregates pass in the LLVM 3.2 release the call SROA::isSafeGEP() will now allow alloca scalarization in the case where a GEP index into a vector isn’t a constant. My question is: what is the expected behavior when the index is out of bounds of the vector? Is it undefined? I have an

On 1 July 2011 13:35, Vasiliy Korchagin <vasiliy.korchagin at gmail.com> wrote: > On 01.07.2011 12:03, Eli Friedman wrote: >> On Fri, Jul 1, 2011 at 12:53 AM, Корчагин Василий >> <vasiliy.korchagin at gmail.com>  wrote: >>> The problem is that C backend doesn't support integers wider than 64 >>> bits, but I need to use it on programs with wide

It seems that one of the optimization passes (it seems to be SROA) sometimes transforms computations on vectors of ints to computations on wide integer types; for example, I'm seeing code like the following after optimizations(*): %0 = bitcast <16 x i8> %float2uint to i128 %1 = shl i128 %0, 8 %ins = or i128 %1, 255 %2 = bitcast i128 %ins to <16 x i8> The back end I'm

On 01.07.2011 12:03, Eli Friedman wrote: > On Fri, Jul 1, 2011 at 12:53 AM, Корчагин Василий > <vasiliy.korchagin at gmail.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

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>* > %arrayVal = load <4 x i32>* %XC > store

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>* %XC store <4 x i32>

Jack Howarth wrote: > I've had better luck compiling all of pymol 1.1r2 with > -O4 on darwin9. Everythink links and there appears to be > no regressions in the resulting code. I take it that LTO > in llvm 2.5 is still limited to dead code elimination, > correct? No. libLTO does the equivalent to opt -internalize -ipsccp -globalopt -constmerge -deadargelim -instcombine

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 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 = load <4 x float>* %inArg %mat_alloc = alloca [4 x <4 x

On 19 June 2011 14:44, Suresh Purini <suresh.purini at gmail.com> wrote: >  I am doing few experiments to do understand optimization phase > interactions. Here is a brief description of my experiements. > > 1. I picked the list of machine independent optimizations acting on > llvm IR (those that are enabled at O3). > 2.  for each optimzation in the optimization-list >  

On Wed, Mar 7, 2012 at 12:47 PM, Nicolas Capens <nicolas.capens at gmail.com> wrote: > Hi all, > > I'm implementing a virtual processor which features dynamic register > indexing, and I'm struggling to make LLVM 3.0 produce good code for it. > The register set is implemented as an LLVM array so it can be > dynamically indexed using GEP. However, most of the time the

Hi all, I'm implementing a virtual processor which features dynamic register indexing, and I'm struggling to make LLVM 3.0 produce good code for it. The register set is implemented as an LLVM array so it can be dynamically indexed using GEP. However, most of the time the virtual processor's registers are just statically indexed, and so I expected/hoped the code would be as