[llvm-dev] Reordering of load/stores using MemorySSA

Juneyoung Lee via llvm-dev llvm-dev at lists.llvm.org
Mon Oct 1 21:03:09 PDT 2018


Hello all,

It seems that it is insufficient to
rely on MemorySSA to correctly reorder load/stores.

For example, we have this following code:

v = load q
store 10, p

=>

store 10, p
v = load q // This is incorrect if p and q may alias

In the MemorySSA representation however,
there's no syntactic dependency between load/store,
because MemorySSA before transformation would look like this:

USE(M0) // corresponding to `v = load q`
M1 = DEF(M0) // corresponding to `store 10, p`

Reordering these two nodes does not break syntactic dependency,
hence additional flow-sensitive analysis is needed to check whether
reordering is valid.
To my understanding, GVNHoist seems to do that:
Memory operations in basic blocks are checked by
GVNHoist::hasMemoryUse().


If USE nodes of MemorySSA also have left-hand side, we can correctly
represent this kind of reorderability IMHO.

For the example above:

U1 = USE(M0) // corresponding to `v = load q`
M1 = DEF(M0, U1) // corresponding to `store 10, p`

Now there is a syntactic dependency between M1 and U1, hence
we can syntactically check whether reordering is allowed without any
flow-sensitive analysis.
If the store and load don't alias, we can remove U1 from DEF:

U1 = USE(M0) // corresponding to `v = load q`
M1 = DEF(M0) // corresponding to `store 10, p`

Then, the reordering is valid.

One issue is regarding PHI node: possible solution is to make
two kinds of PHIS - PHIs for DEFs & PHIS for USEs, so there are
at most 2 PHIs.


Does this idea seem to make sense? Any thoughts?

Best Regards,
Juneyoung Lee

-- 

Juneyoung Lee
Software Foundation Lab, Seoul National University
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20181002/e330a088/attachment.html>


More information about the llvm-dev mailing list