[LLVMbugs] [Bug 20807] New: [EarlyCSE, Missed Opt] "unordered" loads and stores can be removed

bugzilla-daemon at llvm.org bugzilla-daemon at llvm.org
Fri Aug 29 14:10:01 PDT 2014


http://llvm.org/bugs/show_bug.cgi?id=20807

            Bug ID: 20807
           Summary: [EarlyCSE, Missed Opt] "unordered" loads and stores
                    can be removed
           Product: libraries
           Version: trunk
          Hardware: PC
                OS: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: Scalar Optimizations
          Assignee: unassignedbugs at nondot.org
          Reporter: listmail at philipreames.com
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified

Created attachment 12958
  --> http://llvm.org/bugs/attachment.cgi?id=12958&action=edit
Failing test case for EarlyCSE

In EarlyCSE, we currently bail on any load or store which is not isSimple. 
This condition includes both volatiles and atomics which is slightly more
conservative than we need to be.  If a load or store is non-volatile and is
atomic "unordered", there is no additional visibility or ordering requirements
impossed by the memory model.  We should be able to remove these loads and
stores, provided that the value we're forwarding from/removing in favor of are
also "unordered".  

The only dangerous transformations would be to a) use a normal load value in
place of an atomic load (the other direction is fine) or b) remove an atomic
store based on a following normal store.   

Here's one example case (also attached):
@y = common global i32 0, align 4
define i32 @test1() nounwind uwtable ssp {
entry:
  store atomic i32 0, i32* @y unordered, align 4
  ; we can remove this load and forward the store value
  %v = load atomic i32* @y unordered, align 4
  ret i32 %v
}

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20140829/276e3eb2/attachment.html>


More information about the llvm-bugs mailing list