[PATCH] D26127: [MemorySSA] Repair AccessList invariants after insertion of new MemoryUseOrDef.

[bryant via llvm-commits]

bryant added a comment.

>> bryant created this revision.
>>  bryant added reviewers: dberlin, george.burgess.iv.
>>  bryant added a subscriber: llvm-commits.
>>  bryant set the repository for this revision to https://reviews.llvm.org/diffusion/L/ LLVM.
> 
> 
> 
>> An invariant of AccessLists is that the defining access of a Use or Def is the nearest preceding Def node.
> 
> False
>  This is correct for def's but not for uses.
> 
>> For instance, within a BasicBlock:
> 
> 
> 
>>   0 = MemoryDef(liveOnEntry)
>>   1 = MemoryDef(0)
>>   2 = MemoryUse(n)
>>   3 = MemoryDef(m)
> 
> 
> 
>> 1 is the nearest parent Def of 2 and 3, and m and n must be 1.
> 
> Given the above, this is incorrect.
>  n may be 0
> 
> IE the following is perfectly legal
> 
>   0 = MemoryDef(liveOnEntry)
>   1 = MemoryDef(0)
>   2 = MemoryUse(0)
>   3 = MemoryDef(1)
>     

Thanks for clearing up my misunderstanding regarding MemoryUses.

>> This patch simplifies the interfaces of createMemoryAccessBefore/After, and augments them to maintain this invariant.
> 
> 
> 
>> Additionally, when inserting a new Def after an existing Def, there is currently no (clean) way to update the users of the old Def to use the new Def.
> 
> RAUW works exactly to do this case.

I'm not so sure that it's sufficient. Suppose, for instance, that I wanted to insert a MemoryDef between 1 and 2 in the below AccessList:

  0 = MemoryDef(liveOnEntry)
  1 = MemoryDef(0)
  2 = MemoryDef(1)
  3 = MemoryUse(1)

Invoking createMemoryAccess followed by RAUW of 1's uses with 4 would result in:

  0 = MemoryDef(liveOnEntry)
  1 = MemoryDef(0)
  4 = MemoryDef(4)   ; <=======
  2 = MemoryDef(4)
  3 = MemoryUse(4)

So RAUW needs to happen before setting 4's defining access to 1, but this isn't possible with the current createDefiningAccess. What other options are there? RAUW with a bogus Def, create, then re-RAUW to the newly created Def? I feel like I'm missing something obvious, so clarification would be much appreciated.


Repository:
  rL LLVM

https://reviews.llvm.org/D26127