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

[Daniel Berlin via llvm-commits]

On Tue, Aug 23, 2016 at 12:04 PM, Philip Reames <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 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.



> 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/4f08186b/attachment.html>