[PATCH] D16743: This patch hijacks Danny's MemorySSA, a virtual SSA form for memory. Details on what it looks like are in MemorySSA.h

George Burgess IV via llvm-commits llvm-commits at lists.llvm.org
Fri Jan 29 17:51:29 PST 2016

george.burgess.iv created this revision.
george.burgess.iv added reviewers: nlewycky, hfinkel.
george.burgess.iv added subscribers: davidxl, hliao, anemet, pete, tvvikram, dberlin, zneak, majnemer, jmolloy, reames, sanjoy, llvm-commits.

**Note:** This is a continued review from D7864. I can’t figure out how to take ownership of that revision, so I made my own. Reviewers/subscribers were taken from said revision.

Changes to the prior patch:

Did a minor overhaul of the code + added tests. On the whole, the algorithms are the same.

Changes in more words:
  - Took out the update API at Danny’s request
  - Added a few tests, including the case that Hal mentioned (at multiple-backedges-hal.ll )
  - Added an abstract MemoryUseOrDef class to more cleanly separate `MemoryUse`s from `MemoryDef`s
  - A few minor bug fixes
  - A few minor optimizations (took out some virtual functions, stored things in e.g. `PointerIntPair`s, ...)
  - Minor refactors throughout in an attempt to improve code clarity and robustness

There are a few FIXMEs scattered about that I’ll address before committing, and a few that I won’t (read: no plans to fix the FIXMEs in MemoryAccess before upstreaming this. That will probably come when MemorySSA becomes more mature/has most of its APIs ironed out and implemented).

If anything seems sketchy, please let me know. I’m about 98% sure I know how everything’s meant to work, so I could certainly be wrong. :)

Any suggestions for more test cases are appreciated, as well. I plan to add a few more prior to upstreaming, but this is more or less what I could come up with.

Old summary:

There is no grand scheme to use this across LLVM (at least, that i have). 
The main purposees for it are to clean and speed up things like MemoryDependenceAnalysis
(which spends a lot of time walking to find use/defs of memory, etc), and to 
be able to provide load value numbering to GVN (and PRE).
Secondarily, it may be possible to speed up some of the other load/store
motion passes using it.

Note that creation of MemorySSA is linear time and space relative to the IR
size. It uses the same linear time phi placement algorithm PromoteMemoryToRegisters does
(though sadly, not the same code because abstracting PromoteMemoryToRegisters
is not easy since we don't derive the memory access classes from things
like Value, etc)

It's lived both as a utility that passes could create and delete, and as a pass.
In the current patch, it's a functionpass that things can require
as an analysis.
Happy to put it back to being a utility, not sure which makes more sense.
I only have GVN using it right now.

As a small note: The immediate-use lists are ugly right now. Suggestions for how to do
that better welcome.

Anyway, happy to answer any questions, and not looking to commit this tomorrow,
more it got to the point where i think it would be good to get some other eyes
on it.



-------------- next part --------------
A non-text attachment was scrubbed...
Name: D16743.46450.patch
Type: text/x-patch
Size: 88001 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20160130/b3e5ea94/attachment.bin>

More information about the llvm-commits mailing list