llvm dev - Jan 2018 - MemDep: Invalidating NonLocal result cache entries?

Hi,

MemDep caches results for local queries and provides means to
invalidate them by keeping reverse maps. Unfortunately, it also caches
results that represent non-local dependencies, for which there are no
reverse map entries, and thus those entries can not be invalidated.

This is a problem when an optimization turns a non-local dependency
into a local one.
https://bugs.llvm.org//show_bug.cgi?id=36063 is an example for this.

One way to avoid this bug specifically is to mark MLSM as not
preserving MemDep. But a pass that both relies on MemDep and does
sinking like MLSM would be prone to hitting the same bug again,
without any means to avoid it. So I wonder what's the best approach
here.

1) Mark MLSM as not preserving MemDep.
2) Don't cache NonLocal results.
3) Add a map to track which basic blocks have NonLocal results cached
and invalidate them when certain instructions are added to a basic
block.

Cheers,
Björn

+ Gerolf

On Fri, Jan 26, 2018 at 4:18 AM, Björn Steinbrink via llvm-dev
<llvm-dev at lists.llvm.org> wrote:
> Hi,
>
> MemDep caches results for local queries and provides means to
> invalidate them by keeping reverse maps. Unfortunately, it also caches
> results that represent non-local dependencies, for which there are no
> reverse map entries, and thus those entries can not be invalidated.
>
> This is a problem when an optimization turns a non-local dependency
> into a local one.
> https://bugs.llvm.org//show_bug.cgi?id=36063 is an example for this.
>
> One way to avoid this bug specifically is to mark MLSM as not
> preserving MemDep. But a pass that both relies on MemDep and does
> sinking like MLSM would be prone to hitting the same bug again,
> without any means to avoid it. So I wonder what's the best approach
> here.
>
> 1) Mark MLSM as not preserving MemDep.
> 2) Don't cache NonLocal results.
> 3) Add a map to track which basic blocks have NonLocal results cached
> and invalidate them when certain instructions are added to a basic
> block.
>
> Cheers,
> Björn
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev


-- 
Davide

"There are no solved problems; there are only problems that are more
or less solved" -- Henri Poincare