[PATCH] D15537: limit the number of instructions per block examined by dead store elimination

[Philip Reames via llvm-commits]

On 08/23/2016 12:18 PM, Daniel Berlin wrote:
>
>
> On Tue, Aug 23, 2016 at 12:04 PM, Philip Reames 
> <listmail at philipreames.com <mailto:listmail at philipreames.com>> wrote:
>
>     reames added inline comments.
>
>     ================
>     Comment at: lib/Transforms/Scalar/DeadStoreElimination.cpp:490
>     @@ -489,3 +489,3 @@
>        // Do a top-down walk on the BB.
>        for (BasicBlock::iterator BBI = BB.begin(), BBE = BB.end(); BBI
>     != BBE; ) {
>          Instruction *Inst = &*BBI++;
>     ----------------
>     I'm wondering whether we can solve the practical problem with a
>     caching change.
>
>     What if we simply chose to cache the intermediate MDA results? 
>     (Note that MDA does not do this for the getPointerDependencyFrom
>     interface.)
>
> FWIW: It's caching is also mostly broken for 
> getNonLocalPointerDependency (if you call it 100000 times on the same 
> inputs, you can see this).
>
>
>     I'm picturing a simple cache structure of Map<pair<MemoryLoc,
>     Instruction>, MemDepResult>
>
>
> This is hugely expensive in practice if you keep the cache ;)
>
> This is precisely what we did in MemorySSA back in the day, and i did 
> precisely this with GVN before i started building MemorySSA.  The 
> memory usage on larger testcases is "huge", to say the least.
> MemoryLoc's are not very cheap these days.
>
> They are Ptr, Size, AATags (which is a struct with 3 pointers).
> They are copied by value everywhere, too :(
>
> If we had an LRU (or whatever) cache datastructure, where we could say 
> "store 100 things", this would probably make for a good stopgap.
This seems like a very reasonable thing to implement.
>
>
>     This wouldn't reduce the worst case complexity (it could be each
>     instruction has a different memory location associated with it
>     which is may alias with all others),
>
>
> It's not just memloc, they could have different size or tbaa, etc.
Isn't that part of the memory location class?  (Oh, I see the 
confusion.  I didn't mean "location in memory"; I meant "location in 
memory as described by a "MemoryLoc". )
>
>     but how many unique memory locations do we see in practice?  And
>     out of those, how many are mayalias (i.e. not a possible read or
>     def which terminates a chain)?
>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20160823/10b1067c/attachment.html>