[PATCH] D15706: [Polly] Follow uses to create value MemoryAccesses

Michael Kruse via llvm-commits llvm-commits at lists.llvm.org
Mon Feb 1 08:30:17 PST 2016

Meinersbur added a comment.

In http://reviews.llvm.org/D15706#340524, @grosser wrote:

> From the commit message:
> > Because it does not catch all uses (e.g. those by PHIs), some code adds more scalar reads write on the fly, with relatively conditions and possible creation of MemoryAccesses that are not required.

s/relatively conditions/relatively complicated conditions

> Is this still correct? As far as I see, this patch does not reduce the number of memory accesses modeled. Maybe this functionality was already committed with the previous patch?

This describes the situation in current trunk.

> Also, I do not yet fully understand why we add new accesses in "test/ScopInfo/invariant-loads-leave-read-only-statements.ll". Could you maybe point out again the reason why we need to add more load accesses.

This is something I forgot. Before the ScopRIL.count was tested on definitions (always LoadInsts), after with this it actually iterates over uses. I moved the ScopRIL.count to ensureValueLoad so it also tests whether an access is not required because is it will be hoisted.

This was also the reason behing the TODO in invariant_load_scalar_escape_alloca_sharing.ll, because the ScopRIL.count  was checked only after buildPHIAccesses.

> My feeling was that this is an [NFC] patch when ignoring the order of the generated memory accesses.


More information about the llvm-commits mailing list