[PATCH] D25172: [MSSA] Initial version of avoiding unnecessary use walks when calling getClobberingMemoryAccess

[Daniel Berlin via llvm-commits]

Sigh.

Two things need your thoughts on george.

First, it looks like your attempt to add basicAA in setupAnalyses is not
doing anything:
 76   AliasResult AAResults::alias(const MemoryLocation &LocA,
   77                               const MemoryLocation &LocB) {
-> 78    for (const auto &AA : AAs) {
   79      auto Result = AA->alias(LocA, LocB);
   80      if (Result != MayAlias)
   81        return Result;
(lldb) p AAs
(std::__1::vector<std::__1::unique_ptr<llvm::AAResults::Concept,
std::__1::default_delete<llvm::AAResults::Concept> >,
std::__1::allocator<std::__1::unique_ptr<llvm::AAResults::Concept,
std::__1::default_delete<llvm::AAResults::Concept> > > >) $33 = size=0 {}



Simple way to see this:

In the unit test, the following:
  Type *Int8 = Type::getInt8Ty(C);
  Value *AllocaA = B.CreateAlloca(Int8, ConstantInt::get(Int8, 1), "A");
  Instruction *SIA = B.CreateStore(ConstantInt::get(Int8, 0), AllocaA);
  Value *AllocaB = B.CreateAlloca(Int8, ConstantInt::get(Int8, 1), "B");
  Instruction *SIB = B.CreateStore(ConstantInt::get(Int8, 0), AllocaB);
  Instruction *LIA = B.CreateLoad(AllocaA);

results in:
define void @F() {
  %A = alloca i8, i8 1
; 1 = MemoryDef(liveOnEntry)
  store i8 0, i8* %A
  %B = alloca i8, i8 1
; 2 = MemoryDef(1)
  store i8 0, i8* %B
; MemoryUse(2)
  %1 = load i8, i8* %A
}

(The load is not being optimized because there is no AA).

Second, we can only reset optimized properly if all operand setting is done
through setDefinedAccess.

We have no way to catch all the Use.set's that i can find.

If that's correct, i'll drop the optimized flag, and just keep the part to
reset setDefiningAccess.

This means we will still pay a cost for calling getclobberingmemoryaccess
on loads.


On Sun, Oct 2, 2016 at 7:39 PM, Daniel Berlin <dberlin at dberlin.org> wrote:

> dberlin added a comment.
>
> (Unittest that resets the defining access, and calls getClobberingAccess,
> coming)
>
>
> https://reviews.llvm.org/D25172
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20161002/2c1a1e8b/attachment.html>