[LLVMbugs] [Bug 24156] New: Missed store-load forwarding due to release fence
bugzilla-daemon at llvm.org
bugzilla-daemon at llvm.org
Thu Jul 16 11:34:55 PDT 2015
https://llvm.org/bugs/show_bug.cgi?id=24156
Bug ID: 24156
Summary: Missed store-load forwarding due to release fence
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
Given the following IR fragment:
define i32 @test(i32* %addr.i) {
store i32 5, i32* %addr.i, align 4
fence release
%a = load i32, i32* %addr.i, align 4
ret i32 %a
}
Neither GVN or EarlyCSE appears to be able to forward the value of the load in
question. At least if my understanding of fence semantics is correct - which
it might not be - we should be able to forward the value of the store over the
release fence. To phrase that differently, it's legal to reorder the load
before the release fence; it's not legal to reorder the store after the fence.
The former is sufficient to allow the forwarding in this case.
My best guess is that we're being too conservative in two ways:
- In EarlyCSE, a fence is modelled as a mayWrite operation. In practice, we
should only need to clear the last store, not the set of available loads.
- In MemoryDependenceAnalysis, I believe we just give up on fences. We could
instead look past a release fence if the query value was a load. I'm not sure
about the semantics of store QueryInst.
--
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/20150716/6ec76c7a/attachment.html>
More information about the llvm-bugs
mailing list