[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