similar to: Generalizing load/store promotion in LICM

(minor inline additions) On 09/13/2018 01:51 AM, Chandler Carruth wrote: > Haven't had time to dig into this, but wanted to add +Alina Sbirlea > <mailto:asbirlea at google.com> to the thread as she has been working on > promotion and other aspects of LICM for a long time here. Thanks! > On Wed, Sep 12, 2018 at 11:41 PM Philip Reames > <listmail at philipreames.com

For doing PRE on the load, it looks like there’s only two things stopping GVN PRE from doing it: * GVN::PerformLoadPRE doesn’t hoist loads that are conditional. Probably this can be overcome with some kind of heuristic that allows it to happen in loops when the blocks where a load would have to be inserted are outside the loop. * IsFullyAvailableInBlock goes around the loop and

On Fri, Sep 14, 2018 at 4:25 PM Philip Reames <listmail at philipreames.com> wrote: > This is going OT from the original thread, but, what the heck... > Sorry, not my intention, I was just giving another reason why getting promotion done in LICM differently would be helpful. > Alina, can you explain the challenge with implementing promotion over > MemorySSA? On the surface, it

Hi Ashutosh, > On Mar 16, 2015, at 9:06 PM, Nema, Ashutosh <Ashutosh.Nema at amd.com> wrote: > > Hi Adam, > > From: Adam Nemet [mailto:anemet at apple.com <mailto:anemet at apple.com>] > Sent: Wednesday, March 11, 2015 10:48 AM > To: Nema, Ashutosh > Cc: llvmdev at cs.uiuc.edu <mailto:llvmdev at cs.uiuc.edu> > Subject: Re: [LLVMdev] RFC: Loop

Hi Andy, Andrew Trick wrote: > > I don’t remember why this is important. I often don't know with > InstCombine whether something is needed to expose IR optimization or an > ISEL pattern (which should really be somehow denoted and only run in a > later pass). But for the purposes of this discussion, only the legality (or lack thereof) of the above transform matters, not

> On Mar 19, 2015, at 9:46 PM, Nema, Ashutosh <Ashutosh.Nema at amd.com> wrote: > > Thanks Adam for your reply. > > From: Adam Nemet [mailto:anemet at apple.com <mailto:anemet at apple.com>] > Sent: Friday, March 20, 2015 3:23 AM > To: Nema, Ashutosh > Cc: Hal Finkel; Philip Reames; llvmdev at cs.uiuc.edu <mailto:llvmdev at cs.uiuc.edu> > Subject:

I'm attempting to add some support for hoisting/sinking of memory-using intrinsics in loops, and so I want to use MemoryDependenceAnalysis in LICM, but when I modify getAnalysisUsge to include this : virtual void getAnalysisUsage(AnalysisUsage &AU) const { AU.setPreservesCFG(); AU.addRequired<DominatorTree>(); AU.addRequired<LoopInfo>();

Hi, In the IR below, %tmp.7 and %tmp.8 are not used in loop, so we can sink them in exit blocks. However, LICM do not handle this case because of the check in isNotUsedInLoop() which returns false when a PHI node use is hooked from a block inside the loop. I'm not sure if we really need to have this check even when the PHI is outside the loop? define i32 @test7(i32 %N, i32 %N2, i1 %C) {

> On Mar 20, 2015, at 8:02 PM, Nema, Ashutosh <Ashutosh.Nema at amd.com> wrote: > > > Yes, this is what I was proposing above and here ;): > Thanks Adam it’s for confirming J NP :). > > > No, not hasLoopInvariantStore but hasAccessToLoopInvariantAddress. > Its only for invariant stores[not loads], Using ‘hasLoopInvariantStore’ (or a name with invariant store)

On Dec 14, 2011, at 7:09 AM, David Gardner wrote: > I'm attempting to add some support for hoisting/sinking of memory-using > intrinsics in loops, and so I want to use MemoryDependenceAnalysis in > LICM, but when I modify getAnalysisUsge to include this : > > virtual void getAnalysisUsage(AnalysisUsage &AU) const { > AU.setPreservesCFG(); >

On 06/12/2015 04:14 PM, Andrew Trick wrote: >> On Jun 12, 2015, at 2:52 PM, Philip Reames <listmail at philipreames.com> wrote: >> >> >> >> On 06/12/2015 02:10 PM, Andrew Trick wrote: >>>> On Jun 12, 2015, at 2:06 PM, Daniel Berlin <dberlin at dberlin.org> wrote: >>>> >>>> On Fri, Jun 12, 2015 at 2:03 PM, Andrew Trick

On 06/12/2015 02:10 PM, Andrew Trick wrote: >> On Jun 12, 2015, at 2:06 PM, Daniel Berlin <dberlin at dberlin.org> wrote: >> >> On Fri, Jun 12, 2015 at 2:03 PM, Andrew Trick <atrick at apple.com> wrote: >>> On Jun 12, 2015, at 1:51 PM, Daniel Berlin <dberlin at dberlin.org> wrote: >>> >>> So, you can't have disjoint sets, and have

On Fri, Jun 12, 2015 at 2:03 PM, Andrew Trick <atrick at apple.com> wrote: > > On Jun 12, 2015, at 1:51 PM, Daniel Berlin <dberlin at dberlin.org> wrote: > > So, you can't have disjoint sets, and have one of set that says "i > access everything". Because it would contain everything :) > > Thus, I assume by your description you meant "we want to

Thanks for the background on the concurrent memory model. So, is it sufficient that the loop entry is guarded by condition (cbz at top) for preventing the race? The loop entry will be guarded by condition if 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

I think gcc is right. It inserted a branch for n == 0 (the cbz at the top), so that's not a problem. In all other regards, this is safe: if you examine the sequence of loads and stores, it eliminated all but the first load and all but the last store. How's that unsafe? If I had to guess, the bug here is that LLVM doesn't want to hoist the load over the condition (which it is right

Hi All, I'm looking into converting LICM to use MemorySSA instead of AliasSets to determine when it is safe to hoist/sink/promote loads and stores to get around the issue of alias set collapse (see discussion [1]). I have a prototype implementation, but have run into two issues that I could use input from the designers of MemorySSA to resolve: 1) Is MemorySSA intended to be

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

Hi all, I just noticed that LICM does not hoist/sink the following store out of the loop: int array[20]; int i; for (i = 0; i<100; i++) { array [0] = 0; } The getElementPtr instruction is hoisted out of the loop; the store is not. Did I miss something obvious? Bitcode file attached. Generated using LLVM 2.5 and llvm-gcc -c -emit-llvm

On Oct 27, 2009, at 9:26 AM, Nick Lewycky wrote: > 2009/10/27 Marc Brünink <marc at bruenink.de> > Hi all, > > I just noticed that LICM does not hoist/sink the following store out > of the loop: > > int array[20]; > int i; > for (i = 0; i<100; i++) { > array [0] = 0; > } > > The getElementPtr instruction

Hi Daniel, Thanks for the info. I’ve started looking into converting EarlyCSE to use MemorySSA first since 1) I don’t think it needs any additional MemorySSA update API and 2) the particular case I’m looking at needs EarlyCSE to catch more load cases before LICM to be profitable. I have a prototype working, but have run into two issues: 1) readonly calls are treated as clobbers by