search for: makam

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

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

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 Eli, I was looking at this code which keeps track of loop headers but is checking if the destination of branch i...

...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. My point was that just hoisting/sinking unconditionally the memory accesses is unsound. It is good news that gcc learnt how to do it...

Hi All, In the attached test case there, is an unnested loop with 2 iterations. The loop latch block is terminated by an unconditional branch, so simplifycfg folds the almost empty latch block into its predecessor which is the loop header. This results in an additional backedge in the CFG, so when LoopRotate pass is called it canonicalizes the loop into a nested loop. However, now the loop

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 at cs.u...

...ned 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 > >> Behalf Of E...

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

...{ 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 &gt...

...y 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. Because our...

...gt; }; >> >> > > >> >> > > 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 Mess...

...gt; }; >> >> > > >> >> > > 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 Mess...

...gt;> >> > > 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. >> >> >> >> >> >> &...

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 conditional then it is not safe because it would break the LLVM concurrency model (See commit 73bfa4a). It has an IR test for checking this in test/Transforms/LICM/scalar-promote-memmodel.ll However, I have

...gt;> >> > > 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. >> >> >> >> >> >> &...

...gt;> >> > > 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 =

...9;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. >> &...

...9;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. >> &...