[PATCH] D7864: This patch introduces 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
Mon Feb 1 20:20:15 PST 2016

george.burgess.iv added a comment.

> Explicitly LGTM as well. I'm really looking forward to having this in tree so that we can start experimenting and iterating on top of it.

Thanks! (Also, naturally, thanks to everyone who reviewed/commented/... :) )

> I don't think we're going to be ready to switch the default for a while yet, but being able to iterate and work through the bugs in tree is going to be very empowering and will likely speedup progress.

It seems that there are a number of people who are concerned about subtle bugs (both in MemorySSA, and in user code -- especially if this lets us optimize code in new and exciting ways). So, I agree that making this opt-in for a time is a good idea.

> What's your planned next step? I'd suggest implementing a very simple pass which just runs obvious peepholes over the MemorySSA representation. (e.g. a MemCombine pass). My suspicion is that will be a good way to stress the implementation and might even be profitable enough to just turn on by default. In particular, a pass that got the easy forms of cross block DSE would be very useful.

I don't have any plans. If we want to port existing passes soon, we'll either need an update API, or we'll need to restrict ourselves to passes that don't use the update API. Also, we'll need a wrapper that either queries MemDep or MemorySSA if we want to have a global "use MemorySSA?" flag. If we think making a simple MemorySSA-based DSE pass would be a better first step, I'm fine doing that, as well. Same thing goes for readding the optimizations that were stripped out today.

So long as progress is made, I'm happy. :)


More information about the llvm-commits mailing list