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

Daniel Berlin via llvm-commits llvm-commits at lists.llvm.org
Sun Oct 30 11:04:33 PDT 2016


On Sun, Oct 30, 2016 at 3:03 AM, bryant <3.14472+reviews.llvm.org at gmail.com>
wrote:

> 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 rL 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)


>
> 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.


> So createDefiningAccess now permits the option of updating the users.
>

Please, no.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20161030/c7cbc266/attachment.html>


More information about the llvm-commits mailing list