[PATCH] D64405: [DependenceAnalysis] Dependecies for loads marked with "ivnariant.load" should not be shared with general accesses. Fix for https://bugs.llvm.org/show_bug.cgi?id=42151

Evgeniy via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Thu Jul 18 05:16:27 PDT 2019


ebrevnov added a comment.

In D64405#1590778 <https://reviews.llvm.org/D64405#1590778>, @ebrevnov wrote:

> In D64405#1589715 <https://reviews.llvm.org/D64405#1589715>, @reames wrote:
>
> > I'd like to suggest a change of approach here.  There's already precedent in the code for dealing with inconsistent results from metadata.  See the getNonLocalPointerDepFromBB handling for AATags and Size changes.  I don't see a reason why invariant_load can't be handled in the same manner in the same place.  Doing that consolidates all the cache invalidation in one place, and has the benefit of caching all accesses with as much precision as possible. (i.e. an invariant_load would be cached as invariant until the first normal load from that location was found, and then cached as normal loads)
>
>
> Thanks for the suggestion.  Will take a look.


These two cases for Size/AATags turned out to be different than invariant load one. In the former case when cache data is invalid it is updated with a new one and all subsequent queries for both new and old Size/AATags will be satisfied from the cache. In case of invariant load we need to always keep two distinct results (except the case pointed out by Johannes) otherwise we won't optimize out invariant loads what completely defeats the idea of marking loads as invariant.  Please let me know if I'm missing something here.


Repository:
  rL LLVM

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D64405/new/

https://reviews.llvm.org/D64405





More information about the llvm-commits mailing list