[PATCH] D28147: [LICM] Allow promotion of some stores that are not guaranteed to execute

Michael Kuperstein via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Thu Dec 29 16:17:25 PST 2016


mkuper added inline comments.


================
Comment at: test/Transforms/LICM/scalar_promote.ll:208
+
+loop:
+  %j = phi i32 [ 0, %entry ], [ %next, %loop ]
----------------
reames wrote:
> mkuper wrote:
> > reames wrote:
> > > Looking at this test, it really should be handled by the thread local code we already have.  Have you looked to see why it isn't?
> > > 
> > > In fact, looking at *all* of your tests, the thread local case should handle it...?
> > > 
> > > (Note: This is a very important question to that I'll want an answer to before we commit the semantics parts of this code.)
> > Why would it be handled by the thread-local code?
> > %local is an alloca, so it's not thread-local memory.
> > 
> An alloca is thread local until the first time it escapes and become visible to another thread.  This is the same as a call to malloc().  
> 
> I think the isAllocLikeFn check in the thread local case should become (isAllocLikeFn || isa<AllocaInst>).  I believe that will handle the cases you've mentioned.
> An alloca is thread local until the first time it escapes and become visible to another thread. This is the same as a call to malloc().
Argh, right. 

> I think the isAllocLikeFn check in the thread local case should become (isAllocLikeFn || isa<AllocaInst>). I believe that will handle the cases you've mentioned.
I guess you're right, that will solve most issues. Thanks for the (failed :-) ) sanity check.
I think we may want both things, though - this can fire even if the alloca is captured (or if it's a global or a function argument instead of the alloca), if bar is argmemonly/readnone. 


https://reviews.llvm.org/D28147





More information about the llvm-commits mailing list