similar to: [LLVMdev] Benchmarks for dead code elimination?

Hi Cristianno, On 01/06/13 01:49, Cristianno Martins wrote: > Hello there, > > I'm writing a transformation pass for LLVM, and I hoped to use dce to clean up > the resulting code after my pass. I just have some questions about LLVM's dce > implementation. > > Well, my transformation is a function pass, and, after the changes are made, > some instructions are not

Hello there, I'm writing a transformation pass for LLVM, and I hoped to use dce to clean up the resulting code after my pass. I just have some questions about LLVM's dce implementation. Well, my transformation is a function pass, and, after the changes are made, some instructions are not needed anymore. In order to easily get rid of those instructions, I'm setting all their uses to

I request additional review of diff: http://reviews.llvm.org/D18762 We noticed that a source of performance difference between llvm and gcc was in dead code elimination. This diff replaces ADCE with a new implementation which will remove control flow and, under option, also remove may-be-infinite loops which are dead. The patch current has "ADCE_new.h" and "ADCE_new.cpp" to

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

David Callahan via llvm-dev <llvm-dev at lists.llvm.org> writes: > Hi, > > I have a new variant of Aggressive Dead Code Elimination that also > removes dead branching. It is designed to minimize the cost of > control-dependence analysis in the common case where almost the entire > program is live. It also can optionally remove dead but > may-be-infinite loops. > >

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

Can you give an example of a case that is missed today but catched by your pass? > On Mar 23, 2016, at 6:43 AM, David Callahan via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > Hi, > > I have a new variant of Aggressive Dead Code Elimination that also removes dead branching. It is designed to minimize the cost of control-dependence analysis in the common case where

Yeah, that was gonna be my question. If so, my view is we should just bite the bullet and start threading post dominance through the compiler. (assuming anyone wants to help. I'm tackling the memoryssa updating stuff with george ATM). On Thu, Mar 24, 2016 at 7:04 PM, Hal Finkel <hfinkel at anl.gov> wrote: > [+Danny] > > ----- Original Message ----- > > From:

On 11/24/2010 03:36 PM, Nick Lewycky wrote: > Andrew Clinton wrote: >> Most of my programs contain loops that the LoopDeletion pass is unable >> to remove. It appears that the following code in LoopDeletion.cpp:152 >> is the culprit: >> >> ScalarEvolution& SE = getAnalysis<ScalarEvolution>(); >> const SCEV *S =

[+Danny] ----- Original Message ----- > From: "Justin Bogner via llvm-dev" <llvm-dev at lists.llvm.org> > To: "David Callahan via llvm-dev" <llvm-dev at lists.llvm.org> > Sent: Wednesday, March 23, 2016 12:36:50 PM > Subject: Re: [llvm-dev] RFC: New aggressive dead code elimination pass > > David Callahan via llvm-dev <llvm-dev at

Hi, I have a new variant of Aggressive Dead Code Elimination that also removes dead branching. It is designed to minimize the cost of control-dependence analysis in the common case where almost the entire program is live. It also can optionally remove dead but may-be-infinite loops. When enabled for –O3 (replacing current ADCE pass) and removing loops, impact on SPEC2006 is in the noise but it

Hi, LLVMer. I use pseudo-instructions ADJCALLSTACK(DOWN | UP) to adjust call stacks, and it works well with "-O0" option. However, ADJCALLSTACK(DOWN | UP) are removed during codegen DCE pass under "-O2". What have I ignored? Thanks. -- 杨勇勇 (Yang Yong-Yong) -------------- next part -------------- An HTML attachment was scrubbed... URL:

You should set them as using/defining your stack register with : let Defs = [STACKREG], Uses = [STACKREG] in { __ YOUR INSTRUCTION __ } Marcello On 04/09/13 07:56, 杨勇勇 wrote: > I use pseudo-instructions ADJCALLSTACK(DOWN | UP) to adjust call > stacks, and it works well with "-O0" option. However, > ADJCALLSTACK(DOWN | UP) are removed during codegen DCE pass under

You should not expect pretty much any perf uplifts from any DCE, ever. If it does, it's mostly luck (better cache behavior, etc). You should expect size improvements ;) On Mon, Aug 1, 2016 at 10:51 PM, Das, Dibyendu via llvm-dev < llvm-dev at lists.llvm.org> wrote: > What kind of perf. uplifts are expected and in what benchmarks/apps ? > > > > *From:* llvm-dev

Make most things update post-dominance info and preserve it. Our other alternative to not take up too much time seems to be invasive surgery on how BB successors/predecessors work so they are a constant time array. I say this because GCC recomputes post-dominators roughly 15-19 times per compilation, and can do it about 3-5x faster than we can. All profiling i've done basically says all our

Andrew Clinton wrote: > Most of my programs contain loops that the LoopDeletion pass is unable > to remove. It appears that the following code in LoopDeletion.cpp:152 > is the culprit: > > ScalarEvolution& SE = getAnalysis<ScalarEvolution>(); > const SCEV *S = SE.getMaxBackedgeTakenCount(L); > if (isa<SCEVCouldNotCompute>(S)) > return

What do you have in mind here? On Thu, Mar 24, 2016, 7:28 PM Daniel Berlin via llvm-dev < llvm-dev at lists.llvm.org> wrote: > Yeah, that was gonna be my question. > If so, my view is we should just bite the bullet and start threading post > dominance through the compiler. > (assuming anyone wants to help. I'm tackling the memoryssa updating stuff > with george ATM).

Thanks Also I found that some cases are also caught by a specialized routine to remove dead loops which is missing the case I noticed. odavd From: Daniel Berlin <dberlin at dberlin.org<mailto:dberlin at dberlin.org>> Date: Thursday, January 28, 2016 at 8:45 PM To: David Callahan <dcallahan at fb.com<mailto:dcallahan at fb.com>>, LLVM Dev Mailing list <llvm-dev at

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

In practice, APT is not faster to build than rdf. The df calculator we use is linear time and quite fast. Updating is also pretty trivial since it's only deletes of dead and unreachable code. So anything it reached can be replaced with undef in most cases. Cd-dce is not slower in GCC than dce On Fri, Jan 29, 2016, 8:31 PM David Callahan <dcallahan at fb.com> wrote: > I think you