similar to: [LLVMdev] opt usage?

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

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

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

On Wednesday 21 May 2008 15:48, Chris Lattner wrote: > > What's the difference between GVN and GCSE, if they both perform common > > subexpression elimination? > > GVN does more, and is a better algorithm. GCSE is basically deprecated > and should be removed at some point. Er...waitaminute. Maybe there's something I don't fully grok about GVN, but in general,

On Thu, 16 Mar 2006, Eric Kidd wrote: > Hello! I'm compiling code which uses pointers as iterators. For some > reason--probably a silly misunderstanding of the docs--I can't eliminate > duplicate pointer loads. I'll probably figure this out eventually, but if > somebody else sees the answer instantly, I certainly won't complain. :-) There are no stupid questions.

Hello! I'm compiling code which uses pointers as iterators. For some reason--probably a silly misunderstanding of the docs--I can't eliminate duplicate pointer loads. I'll probably figure this out eventually, but if somebody else sees the answer instantly, I certainly won't complain. :-) Here are the optimizers I'm running: opt -f -simplifycfg -dce -instcombine

Hi LLVM, I'm currently setting up some tools to investigate the influence of the order of optimization passes on the performance of compiled programs -nothing exceptional here. I noticed something inconvenient with opt, namely that splitting a call does not always give the same output: % llvm-stress > stress.ll % opt -dse -verify -dce stress.ll -o stress-1.bc % opt -dse stress.ll |

Hi Eli, Unfortunately the differences remain, I do not observe a significant change in the output besides the fact that it's random. I noticed that running opt without options on the random file changes the order of references in the predecessors of basic blocks (sample below). Further invocations of opt are idempotent. I don't know of this information is stored in the bytecode file

On Mon, 21 Feb 2005, Jeff Cohen wrote: > I figured getelementptr exists as it does to facilitate data flow analysis, > but it does need to be broken down before instruction selection. It's not > just the missed optimization opportunities. It also introduces a huge amount > of complexity into instruction selection as they deal with its complexity. > It would also take care

Hi Mehdi, Thank you for mentioning this tool, I was looking for something like this. By default the analyzer produces identical output on both files, but a complete -dump shows that the storage order of the symbol table is different. This would explain why text files are not affected: the symbols are used directly in text form so there is no need for this table. I suppose that settles the

On Tue, 22 Feb 2005, Vikram S. Adve wrote: >> The second issue is that we need to do redundancy elimination and hoisting >> on operations that are only exposed once instruction selection is >> performed. Getelementptr expansion is just ONE particular case of this, >> but it can happen with any instructions (including the use of large integer >> (or any FP)

>-----Original Message----- >From: llvmdev-bounces at cs.uiuc.edu >[mailto:llvmdev-bounces at cs.uiuc.edu] On Behalf Of Chris Lattner >Sent: Monday, October 16, 2006 2:09 PM >To: LLVM Developers Mailing List >Subject: Re: [LLVMdev] initializer does not match global variable type. > >On Mon, 16 Oct 2006, Anderson, Todd A wrote: >> I have an objective-c file, bar.m,

After compiling llvm and the cfrontend, I tried to run llvm2cpp on a few of the .ll files in the test/Regression directory. When I try this, I get the following error: llvm2cpp: Invalid bytecode signature: 5552203B (Vers=0,Pos=4) Any help would be appreciated. thanks, Todd

On Mar 16, 2006, at 8:47 PM, Chris Lattner wrote: > On Thu, 16 Mar 2006, Eric Kidd wrote: >> The duplicate loads appear at the top of the %regex6 and %regex2 >> blocks below. I've tried various alias analysis implementations >> either alone or in combination. > > LICM doesn't remove common subexpressions, also -load-vn doesn't > affect LICM. Try

Hi, We have a compiler for the Faust language (faust.grame.fr) that currently compiles a C++ class which implements a DSP plug-in with several methods. Our strategy to compile LLVM IR instead is the following: - use the current Faust ==> C++ compiler to compile a "empty" plug-in that we use as a template C++ class. - compile this template C++ class using "llvm-g++

I'm getting the error below on Ubuntu Hardy on ia32 on r55688. John make[3]: Entering directory `/home/regehr/llvm-gcc/build/gcc' gcc -c -g -DIN_GCC -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -Wold-style-definition -Wmissing-format-attribute -DHAVE_CONFIG_H -I. -I. -I../../gcc

> > Now the problem is obvious.  A two dimensional array access is being > performed by a single instruction.  The arithmetic needed to address > the element is implicit, and therefore inaccessible to optimizations.  > The redundant calculations can not be eliminated, nor can strength > reduction be performed.  getelementptr needs to be broken down into > its constituent

Hi Todd, On Mon, 2006-10-16 at 14:04 -0700, Anderson, Todd A wrote: > >-----Original Message----- > >From: llvmdev-bounces at cs.uiuc.edu > >[mailto:llvmdev-bounces at cs.uiuc.edu] On Behalf Of Chris Lattner > >Sent: Monday, October 16, 2006 2:09 PM > >To: LLVM Developers Mailing List > >Subject: Re: [LLVMdev] initializer does not match global variable type.

> The second issue is that we need to do redundancy elimination and > hoisting on operations that are only exposed once instruction > selection is performed. Getelementptr expansion is just ONE > particular case of this, but it can happen with any instructions > (including the use of large integer (or any FP) constants on RISC > machines, addressing globals with PIC code,

I figured getelementptr exists as it does to facilitate data flow analysis, but it does need to be broken down before instruction selection. It's not just the missed optimization opportunities. It also introduces a huge amount of complexity into instruction selection as they deal with its complexity. It would also take care of many of the FIXMEs in LoopStrengthReduce. Vikram Adve