search for: scalarreplaggreg

...lTy = IntegerType::get(StoredValTy->getContext(), StoreSize); StoredVal = new BitCastInst(StoredVal, StoredValTy, "", InsertPt); } ... here if LoadedTy is Vector type like <4 x i32>, then StoreSize will be 128 bit integer. I will show you some example later. I find in pass ScalarReplAggregates it offers some configuration parameters to control the maximum width of wide integer, which is quite friendly. In SROA, i don't found that kind configuration parameters. Can anybody familiar with 'Scalar' passes give some insights? 2014-09-04 14:23 GMT+08:00 Chandler Carruth <ch...

...8:11 -0000 1.1 > +++ lib/System/Win32/Win32.h 15 Nov 2004 08:45:47 -0000 > @@ -31,3 +31,6 @@ > throw s; > } > > +inline void ThrowErrno(const std::string& prefix) { > + ThrowError(prefix + ": " + strerror(errno)); > +} > Index: lib/Transforms/Scalar/ScalarReplAggregates.cpp > =================================================================== > RCS file: /var/cvs/llvm/llvm/lib/Transforms/Scalar/ScalarReplAggregates.cpp,v > retrieving revision 1.28 > diff -u -r1.28 ScalarReplAggregates.cpp > --- lib/Transforms/Scalar/ScalarReplAggregates.cpp 14 N...

Hi, when I updated the sources today there were several small problems that stopped the windows version from compiling, here are the patches m. -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: win32patches.txt URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20041115/34634455/attachment.txt>

On May 20, 2008, at 8:57 AM, David Greene wrote: > On Tuesday 20 May 2008 07:03, Nicolas Capens wrote: > >> 1) Does ScalarReplAggregates totally superscede >> PromoteMemoryToRegister? I > > Nope, they are different. Mem2Reg is really important if you want > register > allocation. Actually SROA does fully subsume Mem2Reg. It iterates between breaking up aggregates and promoting them to registers. >&g...

...14d98, AST=0x0) at /home/bram/workspace/svn/aspicere2/trunk/llvm/lib/Transforms/ Utils/PromoteMemoryToRegister.cpp:812 #6 0x08744713 in (anonymous namespace)::SROA::performPromotion (this=0x8b14f38, F=@0x8bc8468) at /home/bram/workspace/svn/aspicere2/trunk/llvm/lib/Transforms/ Scalar/ScalarReplAggregates.cpp:130 #7 0x087445ba in (anonymous namespace)::SROA::runOnFunction (this=0x8b14f38, F=@0x8bc8468) at /home/bram/workspace/svn/aspicere2/trunk/llvm/lib/Transforms/ Scalar/ScalarReplAggregates.cpp:101 #8 0x08826499 in llvm::FPPassManager::runOnFunction (this=0x8b15d00, F=@0x8bc8468)...

Hi, I ran into a case where ScalarReplAggregates can not promote an array of vectors into registers, e..g, %a = alloca [8 x <2 x float>], align 8 %arrayidx74597 = getelementptr [8 x <2 x float>]* %a, i32 0, i32 1, i32 0 ; <float*> [#uses=2] %tmp76 = load float* %arrayidx74597, align 8 %arrayidx745...

...some -O > level, and running it at -O0 and using opt to run the passes on > the unoptimized bitcode. However, you wrote earlier: > Finally, llvm-gcc runs the following passes on each function > immediately after it is created: > > CFGSimplification, PromoteMemoryToRegister, > ScalarReplAggregates, InstructionCombining. AFAIK this isn't something that opt can do. Or are these passes run always by llvm-gcc, even with -O0 ?

On Tue, May 20, 2008 at 2:28 PM, Chris Lattner <clattner at apple.com> wrote: > > On May 20, 2008, at 8:57 AM, David Greene wrote: > >> On Tuesday 20 May 2008 07:03, Nicolas Capens wrote: >> >>> 1) Does ScalarReplAggregates totally superscede >>> PromoteMemoryToRegister? I >> >> Nope, they are different. Mem2Reg is really important if you want >> register >> allocation. > > Actually SROA does fully subsume Mem2Reg. It iterates between breaking > up aggregates and promotin...

Hi Chris, Thanks for the detailed explanations. I have a few remaining questions: Am I correct that ScalarReplAggregates is hardly more expensive than Mem2Reg and therefore generally preferable? What would be the code quality implications of using "-dce -simplifycfg" instead of -adce? As far as I understand the algorithms involved, -dce would hardly ever miss a dead instruction if dead stores have alre...

...at /home/bram/workspace/svn/aspicere2/trunk/llvm/lib/Transforms/ > Utils/PromoteMemoryToRegister.cpp:812 > #6 0x08744713 in (anonymous namespace)::SROA::performPromotion > (this=0x8b14f38, F=@0x8bc8468) > at /home/bram/workspace/svn/aspicere2/trunk/llvm/lib/Transforms/ > Scalar/ScalarReplAggregates.cpp:130 > #7 0x087445ba in (anonymous namespace)::SROA::runOnFunction > (this=0x8b14f38, F=@0x8bc8468) > at /home/bram/workspace/svn/aspicere2/trunk/llvm/lib/Transforms/ > Scalar/ScalarReplAggregates.cpp:101 > #8 0x08826499 in llvm::FPPassManager::runOnFunction (this=0x8b1...

On Oct 14, 2008, at 9:50 AM, Mon Ping Wang wrote: > Hi, > > I ran into a case where ScalarReplAggregates can not promote an array > of vectors into registers, e..g, > %a = alloca [8 x <2 x float>], align 8 > %arrayidx74597 = getelementptr [8 x <2 x float>]* %a, i32 0, > i32 1, i32 0 ; <float*> [#uses=2] > %tmp76 = load float* %arrayidx74597, align 8 &g...

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

...mpiling is comparable to C (without any exception handling or garbage collection, so none of the related passes are needed). My first attempt at collecting useful optimizations looks like this: passManager->add(new TargetData(*executionEngine->getTargetData())); passManager->add(createScalarReplAggregatesPass()); // Convert to SSA form passManager->add(createSCCPPass()); // Propagate constants passManager->add(createInstructionCombiningPass()); // Peephole optimization passManager->add(createDeadStoreEliminationPass()); // Dead store elimination passManager-&...

...a case where this is useful, I would like to see it as it make help us make a better decision in this area. -- Mon Ping On Oct 14, 2008, at 11:38 AM, Dan Gohman wrote: > > On Oct 14, 2008, at 9:50 AM, Mon Ping Wang wrote: > >> Hi, >> >> I ran into a case where ScalarReplAggregates can not promote an array >> of vectors into registers, e..g, >> %a = alloca [8 x <2 x float>], align 8 >> %arrayidx74597 = getelementptr [8 x <2 x float>]* %a, i32 0, >> i32 1, i32 0 ; <float*> [#uses=2] >> %tmp76 = load float* %arrayid...

On Tuesday 20 May 2008 07:03, Nicolas Capens wrote: > 1) Does ScalarReplAggregates totally superscede PromoteMemoryToRegister? I Nope, they are different. Mem2Reg is really important if you want register allocation. > think I need it to optimize small arrays, but what is the expected added > complexity? I shouldn't think it would be very expensive at 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 Wed, 21 May 2008, Nicolas Capens wrote: > Thanks for the detailed explanations. I have a few remaining questions: > > Am I correct that ScalarReplAggregates is hardly more expensive than Mem2Reg > and therefore generally preferable? Right. > What would be the code quality implications of using "-dce -simplifycfg" > instead of -adce? As far as I understand the algorithms involved, -dce would > hardly ever miss a dead instruct...

...two is i8. + %tmpS = getelementptr %struct.two* %S, i32 0, i32 0, i32 0 + %tmpD = bitcast %struct.two* %D to i8* + call void @llvm.memmove.i32(i8* %tmpD, i8* %tmpS, i32 4, i32 1) + ret void +} + +declare void @llvm.memmove.i32(i8*, i8*, i32, i32) nounwind Index: lib/Transforms/Scalar/ScalarReplAggregates.cpp =================================================================== --- lib/Transforms/Scalar/ScalarReplAggregates.cpp (revision 56433) +++ lib/Transforms/Scalar/ScalarReplAggregates.cpp (working copy) @@ -530,8 +530,9 @@ return MarkUnsafe(Info); } } + + bool hasVector = fa...

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 example .ll where...

...ar/CMakeLists.txt =================================================================== --- lib/Transforms/Scalar/CMakeLists.txt (revision 85194) +++ lib/Transforms/Scalar/CMakeLists.txt (working copy) @@ -23,6 +23,7 @@ Reassociate.cpp Reg2Mem.cpp SCCP.cpp + SCCVN.cpp Scalar.cpp ScalarReplAggregates.cpp SimplifyCFGPass.cpp -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20091027/d6a8b62d/attachment.html> -------------- next part -------------- A non-text attachment was scrubbed... Name: CMakeList...