search for: balaram

...ing to cross compile talloc-2.3.1 to for our architecture with below command. ./configure --disable-python --enable-gccdeps --show-deps=SHOWDEPS --why-needed=WHYNEEDED --show-duplicates --cross-compile --cross-execute=arm-marvell-linux-gnueabi-gcc --hostcc=arm-none-linux-gnueabi-gcc --prefix=/home/balaram/MOXA/talloc/ Log: root at sfsubuntu11:/home/balaram/MOXA/talloc-2.3.1# ./configure --show-duplicates --cross-compile --cross-execute='arm-marvell-linux-gnueabi-' --host=arm-none-linux-gnueabi --prefix=/home/balaram/MOXA/talloc/ this is python path balaram Setting top to...

I will try to reduce a test case for the regression I found and will update. Thanks, Balaram From: Friedman, Eli [mailto:efriedma at codeaurora.org] Sent: Friday, June 30, 2017 2:54 PM To: Balaram Makam <bmakam at codeaurora.org>; llvm-dev at lists.llvm.org Subject: Re: [llvm-dev] LoopSimplify pass prevents loop unrolling On 6/30/2017 11:38 AM, Balaram Makam wrote: Thanks E...

On 6/30/2017 11:38 AM, Balaram Makam wrote: > > Thanks Eli, > > I was looking at this code which keeps track of loop headers but is > checking if the destination of branch is a loop header sufficient? > This prevents merging empty preheaders into the loop headers as well. > There isn't really any reas...

...loop has been rotated by loop rotate pass. Since LICM runs after loop rotate, we can use ScalarEvolution::isLoopEntryGuardedByCond to check if we can speculatively execute load without causing a race. Is it heavy-handed solution for this problem? I can create a bug if you would like to. Thanks, Balaram From: Robin Morisset [mailto:morisset at google.com] Sent: Tuesday, September 02, 2014 7:40 PM To: Filip Pizlo Cc: Balaram Makam; LLVM Developers Mailing List Subject: Re: [LLVMdev] LICM promoting memory to scalar Ah right, I had missed the cbz, my bad. It is indeed sound under that condition. M...

On 6/30/2017 7:48 AM, Balaram Makam via llvm-dev wrote: > > Edit. Predecessor -> successor. > > *From:* llvm-dev [mailto:llvm-dev-bounces at lists.llvm.org] *On Behalf > Of *Balaram Makam via llvm-dev > *Sent:* Friday, June 30, 2017 10:47 AM > *To:* llvm-dev at lists.llvm.org > *Subject:* [llvm-dev]...

...fix this. Attached testcase: $cat test.c void foo(); bool test(int a, int b, int *c) { bool changed = false; for (unsigned int i = 2; i--;) { int r = a | b; if ( r != c[i]) { c[i] = r; foo(); changed = true; } } return changed; } Thanks, Balaram -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20170630/513f1f20/attachment.html>

...d. > - speculatively executing loads might not be observable in some specific case but may always introduce races, thus introducing undefined behaviour and breaking assumptions that other passes may rely on. > > Best regards, > Robin > > >> On Tue, Sep 2, 2014 at 3:46 PM, Balaram Makam <bmakam at codeaurora.org> wrote: >> All, >> >> If we can speculatively execute a load instruction, why isn’t it safe to hoist it out by promoting it to a scalar in LICM pass? >> >> >> There is a comment in LICM pass that if a load/store is conditi...

...// in Loop: Header=BB0_2 Depth=1 add w8, w8, w1 cmp w8, w0 b.lo .LBB0_2 .LBB0_5: // %for.end ret .Ltmp1: .size _Z3fooii, .Ltmp1-_Z3fooii .ident "clang version 3.6.0 " Thanks, Balaram

that looks like a different fix. The case mentioned by Easwaran is class A{ int foo () { return 1; } ... }; where 'foo' is not explicitly declared with 'inline' keyword. David On Wed, Jun 17, 2015 at 4:07 PM, Balaram Makam <bmakam at codeaurora.org> wrote: > AFAIK, this was fixed in r233817. > > -----Original Message----- > From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] On > Behalf Of Easwaran Raman > Sent: Wednesday, June 17, 2015 6:59 PM > To: llvmdev a...

...e mentioned by Easwaran is > > > > class A{ > > int foo () { return 1; } > > ... > > }; > > > > where 'foo' is not explicitly declared with 'inline' keyword. > > > > David > > > > On Wed, Jun 17, 2015 at 4:07 PM, Balaram Makam <bmakam at codeaurora.org> > wrote: > >> AFAIK, this was fixed in r233817. That was later reverted. > >> > >> -----Original Message----- > >> From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] > On > >> Behal...

...foo () { return 1; } >> > > ... >> > > }; >> > > >> > > where 'foo' is not explicitly declared with 'inline' keyword. >> > > >> > > David >> > > >> > > On Wed, Jun 17, 2015 at 4:07 PM, Balaram Makam <bmakam at codeaurora.org> >> > wrote: >> > >> AFAIK, this was fixed in r233817. >> >> That was later reverted. >> >> > >> >> > >> -----Original Message----- >> > >> From: llvmdev-bounces at cs.uiuc.e...

...identify that an indirect call is virtual and change the comparison (shown at a higher IR level) from if (ptr->foo == A::foo) to if (ptr->_vptr == A::_vtable) This will sink one load from the original block into the less frequently executed if.false block. This opportunity was found by Balaram Makam. 4. New enhancement patch ------------------------- Currently our implementation has the following shortcomings: a. Our heuristics do not depend on the global information on function counts. It could be that none of the indirect call sites are contributing highly to the overall calls. Becau...

...; > > }; >> >> > > >> >> > > where 'foo' is not explicitly declared with 'inline' keyword. >> >> > > >> >> > > David >> >> > > >> >> > > On Wed, Jun 17, 2015 at 4:07 PM, Balaram Makam >> <bmakam at codeaurora.org> >> >> > wrote: >> >> > >> AFAIK, this was fixed in r233817. >> >> >> >> That was later reverted. >> >> >> >> > >> >> >> > >> -----Origina...

...; > > }; >> >> > > >> >> > > where 'foo' is not explicitly declared with 'inline' keyword. >> >> > > >> >> > > David >> >> > > >> >> > > On Wed, Jun 17, 2015 at 4:07 PM, Balaram Makam >> <bmakam at codeaurora.org> >> >> > wrote: >> >> > >> AFAIK, this was fixed in r233817. >> >> >> >> That was later reverted. >> >> >> >> > >> >> >> > >> -----Origina...

...t;> >> >> > > where 'foo' is not explicitly declared with 'inline' keyword. >> >> >> > > >> >> >> > > David >> >> >> > > >> >> >> > > On Wed, Jun 17, 2015 at 4:07 PM, Balaram Makam >> >> <bmakam at codeaurora.org> >> >> >> > wrote: >> >> >> > >> AFAIK, this was fixed in r233817. >> >> >> >> >> >> That was later reverted. >> >> >> >> >> >...

...t;> >> >> > > where 'foo' is not explicitly declared with 'inline' keyword. >> >> >> > > >> >> >> > > David >> >> >> > > >> >> >> > > On Wed, Jun 17, 2015 at 4:07 PM, Balaram Makam >> >> <bmakam at codeaurora.org> >> >> >> > wrote: >> >> >> > >> AFAIK, this was fixed in r233817. >> >> >> >> >> >> That was later reverted. >> >> >> >> >> >...

...t;> >> >> > > where 'foo' is not explicitly declared with 'inline' keyword. >> >> >> > > >> >> >> > > David >> >> >> > > >> >> >> > > On Wed, Jun 17, 2015 at 4:07 PM, Balaram Makam >> >> <bmakam at codeaurora.org> >> >> >> > wrote: >> >> >> > >> AFAIK, this was fixed in r233817. >> >> >> >> >> >> That was later reverted. >> >> >> >> >> >...

Clang adds the InlineHint attribute to functions that are explicitly marked inline, but not if they are defined in the class body. I tried the following patch, which I believe handles the in-class definition case: --- a/lib/CodeGen/CodeGenFunction.cpp +++ b/lib/CodeGen/CodeGenFunction.cpp @@ -630,7 +630,7 @@ void CodeGenFunction::StartFunction(GlobalDecl GD, if (const FunctionDecl *FD =

Hi, It looks like the DeadStoreElimination optimization doesn't work across BasicBlock boundaries. The project I'm working on (https://github.com/trailofbits/mcsema), would tremendously benefit from even simple cross-block DSE. There was a patch to do non-local DSE few years ago (http://lists.cs.uiuc.edu/pipermail/llvmdev/2010-January/028751.html), but seems that the patch was never

...here 'foo' is not explicitly declared with 'inline' keyword. >> >> >> >> > > >> >> >> >> > > David >> >> >> >> > > >> >> >> >> > > On Wed, Jun 17, 2015 at 4:07 PM, Balaram Makam >> >> >> <bmakam at codeaurora.org> >> >> >> >> > wrote: >> >> >> >> > >> AFAIK, this was fixed in r233817. >> >> >> >> >> >> >> >> That was later reverted. >...