similar to: New Aggressive Dead Code Elimination (updated)

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

I have a rewrite of the aggressive dead code elimination pass which handles control flow and allows may-be-infinite loops to be removed under optional flag. Chandler suggested rather than a large change a series of small changes and, while that may not get us to small changes easily, there has been no further commentary on the diff: https://reviews.llvm.org/D18762. Given that, I will plan on

Processing commands for control at bugs.debian.org: > reassign 648146 logcheck-database 1.3.13 Bug #648146 [logcheck-database-1.3.13] ignore.d.server/ssh is too aggressive Warning: Unknown package 'logcheck-database-1.3.13' Bug reassigned from package 'logcheck-database-1.3.13' to 'logcheck-database'. Bug No longer marked as found in versions squeeze. Bug #648146

Is there a way to set how aggressive the inliner pass (createFunctionInliningPass) without going through the command line interface? Is there any reason InlineLimit isn't an argument to the createFunctionInliningPass function? Thanks, Robert

On Mon, 7 Jan 2008, Robert Zeh wrote: > Is there a way to set how aggressive the inliner pass > (createFunctionInliningPass) without going through the command line > interface? Nope. Well, you could call cl::ParseCommandLine yourself (passing in a static array) like llvm-gcc does, but other than that "no". > Is there any reason InlineLimit isn't an argument to the

I think this will do the trick: -------------- next part -------------- A non-text attachment was scrubbed... Name: inliner.patch Type: application/octet-stream Size: 2654 bytes Desc: not available URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20080111/18fad7e6/attachment.obj> -------------- next part -------------- Robert On Jan 8, 2008, at 3:26 PM, Chris Lattner wrote:

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

I have noticed that the contents of per-directory .cvsignore files apply outside their subtrees when using --cvs-exclude in rsync 2.6.0. In the results below, notice how dir1/.cvsignore is applying to a file in dir2. There is no ~/.cvsignore, and the CVSIGNORE variable is unset. % ls -AFR .: dir1/ dir2/ ./dir1: .cvsignore file1 ./dir2: file2.foo % cat dir1/.cvsignore *.foo % /usr/bin/rsync

On Mon, Aug 11, 2014 at 11:44 PM, Kevin Qin <kevinqindev at gmail.com> wrote: > Hi all, > > Thanks for you paying time to look at this issue. I'm not an expert for > C/C++ language, so I can just post some experiment results from LLVM and > GCC. > > If we make minor changes to the test, gcc may give different results. > > #include <stdio.h> > struct

On Mar 13, 2011, at 2:01 PM, Arnaud Allard de Grandmaison wrote: > Hi all, > > The IndVarSimplify pass seems to be too aggressive when it enlarge the induction variable type ; this can pessimize the generated code when the new induction variable size is not natively supported by the target. This is probably not an issue for x86_64, which supports natively all types, but it is a real one

Hi All , We are looking at the C sample i.e extern int i,j; int test() { while(1) { i++; j=20; } return 0; } command used :(clang version 3.8.0-2ubuntu4 (tags/RELEASE_380/final) ) clang -S test.c -O2 the generated asm for x86 .L2: jmp .L2 we understand that,the infinite loop is not deterministic ,compiler is free to treat as that as UB and do aggressive

On Wed, Jun 29, 2016 at 1:43 AM, vivek pandya via llvm-dev < llvm-dev at lists.llvm.org> wrote: > Hello Quentin, > > I see your work on shrink-wrapping optimization at > http://reviews.llvm.org/rL236507 > IPRA has benefited shrink-wrapping optimization ( I have noticed that on > sqlite3 test-case) so I did read Fred Chow's paper and compare that > approach with

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. > >

On Mar 13, 2011, at 2:01 PM, Arnaud Allard de Grandmaison wrote: > Hi all, > > The IndVarSimplify pass seems to be too aggressive when it enlarge the induction variable type ; this can pessimize the generated code when the new induction variable size is not natively supported by the target. This is probably not an issue for x86_64, which supports natively all types, but it is a real one

On 09/09/2016 04:31 PM, Stephen Canon wrote: > Gating this on -Owhatever is dangerous, . We should simply default to the pragma “on” state universally. Why so? [honestly asking, not arguing] My guess: b/c we don`t want programs to give different results when compiled at different "-O<...>" settings with the exception of "-Ofast". At any rate, the above change is

On Sun, Mar 13, 2011 at 5:01 PM, Arnaud Allard de Grandmaison <Arnaud.AllardDeGrandMaison at dibcom.com> wrote: > Hi all, > > The IndVarSimplify pass seems to be too aggressive when it enlarge the induction variable type ; this can pessimize the generated code when the new induction variable size is not natively supported by the target. This is probably not an issue for x86_64,

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:

Edited the Subject. On Fri, Jul 20, 2018 at 5:50 PM, Umesh Kalappa <umesh.kalappa0 at gmail.com> wrote: > Hi All , > > We are looking at the C sample i.e > > extern int i,j; > > int test() > { > while(1) > { i++; > j=20; > } > return 0; > } > > command used :(clang version 3.8.0-2ubuntu4 (tags/RELEASE_380/final) > ) > clang

> On Sep 9, 2016, at 3:27 PM, Steve Canon via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > > > Sent from my iPhone > > On Sep 9, 2016, at 6:21 PM, Abe Skolnik <a.skolnik at samsung.com <mailto:a.skolnik at samsung.com>> wrote: > >> On 09/09/2016 04:31 PM, Stephen Canon wrote: >> >>> Gating this on -Owhatever is dangerous, .

Hi all, Recently, I found gcc can generate faster codes by localizing global variable inside loop and only write back once before function return. Gcc can do this because its alias analysis think it's safe. But for below case, gcc gives different result from -O0 and -O2. #include <stdio.h> struct heap {int index; int b;}; struct heap **ptr; int aa; int main() { struct heap element;