<span>For starters, createDefinedAccess is private, so nobody can use it.</span><div>Second, the API calls that use it explicitly take a defining access to avoid the problem you cite. </div><div><br></div><div>Can you produce a case where normal usage of the update API actually does the wrong thing?</div><div><br></div><div>I'm entirely unsure what actual usage problem you are trying to solve, so I can't help explain how to do it.<br><br><div class="gmail_quote"><div dir="ltr">On Sun, Oct 30, 2016, 1:17 PM Bryant Wong <<a href="mailto:314472@gmail.com">314472@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr" class="gmail_msg">Thanks for clearing up my misunderstanding regarding MemoryUses.<br class="gmail_msg"><div class="gmail_extra gmail_msg"><br class="gmail_msg"><div class="gmail_quote gmail_msg"></div></div></div><div dir="ltr" class="gmail_msg"><div class="gmail_extra gmail_msg"><div class="gmail_quote gmail_msg">On Sun, Oct 30, 2016 at 2:04 PM, Daniel Berlin <span dir="ltr" class="gmail_msg"><<a href="mailto:dberlin@dberlin.org" class="gmail_msg" target="_blank">dberlin@dberlin.org</a>></span> wrote:<br class="gmail_msg"><blockquote class="gmail_quote gmail_msg" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr" class="gmail_msg"><br class="gmail_msg"><div class="gmail_extra gmail_msg"><br class="gmail_msg"><div class="gmail_quote gmail_msg"><span class="m_-6466548616601174784m_7998958474538251886gmail- gmail_msg">On Sun, Oct 30, 2016 at 3:03 AM, bryant <span dir="ltr" class="gmail_msg"><<a href="mailto:3.14472+reviews.llvm.org@gmail.com" class="gmail_msg" target="_blank">3.14472+reviews.llvm.org@gmail.com</a>></span> wrote:<br class="gmail_msg"><blockquote class="gmail_quote gmail_msg" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">bryant created this revision.<br class="gmail_msg">
bryant added reviewers: dberlin, george.burgess.iv.<br class="gmail_msg">
bryant added a subscriber: llvm-commits.<br class="gmail_msg">
bryant set the repository for this revision to rL LLVM.<br class="gmail_msg">
<br class="gmail_msg">
An invariant of AccessLists is that the defining access of a Use or Def is the nearest preceding Def node.</blockquote></span><div class="gmail_msg">False</div><div class="gmail_msg">This is correct for def's but not for uses.</div><span class="m_-6466548616601174784m_7998958474538251886gmail- gmail_msg"><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg"> </div><blockquote class="gmail_quote gmail_msg" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"> For instance, within a BasicBlock:<br class="gmail_msg">
<br class="gmail_msg">
  0 = MemoryDef(liveOnEntry)<br class="gmail_msg">
  1 = MemoryDef(0)<br class="gmail_msg">
  2 = MemoryUse(n)<br class="gmail_msg">
  3 = MemoryDef(m)<br class="gmail_msg">
<br class="gmail_msg">
1 is the nearest parent Def of 2 and 3, and m and n must be 1.<br class="gmail_msg"></blockquote><div class="gmail_msg"><br class="gmail_msg"></div></span><div class="gmail_msg">Given the above, this is incorrect.</div><div class="gmail_msg">n may be 0</div><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">IE the following is perfectly legal</div><div class="gmail_msg"><span class="m_-6466548616601174784m_7998958474538251886gmail- gmail_msg">  0 = MemoryDef(liveOnEntry)<br class="gmail_msg">  1 = MemoryDef(0)<br class="gmail_msg"></span>  2 = MemoryUse(0)<br class="gmail_msg">  3 = MemoryDef(1)<br class="gmail_msg"></div><span class="m_-6466548616601174784m_7998958474538251886gmail- gmail_msg"><div class="gmail_msg"> </div><blockquote class="gmail_quote gmail_msg" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br class="gmail_msg">
This patch simplifies the interfaces of createMemoryAccessBefore/After, and augments them to maintain this invariant.<br class="gmail_msg">
<br class="gmail_msg">
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. </blockquote><div class="gmail_msg"><br class="gmail_msg"></div></span><div class="gmail_msg">RAUW works exactly to do this case.</div><span class="m_-6466548616601174784m_7998958474538251886gmail- gmail_msg"><div class="gmail_msg"> </div></span></div></div></div></blockquote><div class="gmail_msg"><br class="gmail_msg"></div></div></div></div><div dir="ltr" class="gmail_msg"><div class="gmail_extra gmail_msg"><div class="gmail_quote gmail_msg"><div class="gmail_msg">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:</div></div></div></div><div dir="ltr" class="gmail_msg"><div class="gmail_extra gmail_msg"><div class="gmail_quote gmail_msg"><div class="gmail_msg"><br class="gmail_msg"><br class="gmail_msg"><span class="m_-6466548616601174784m_7998958474538251886gmail- gmail_msg">  0 = MemoryDef(liveOnEntry)<br class="gmail_msg">  1 = MemoryDef(0)<br class="gmail_msg"></span></div></div></div></div><div dir="ltr" class="gmail_msg"><div class="gmail_extra gmail_msg"><div class="gmail_quote gmail_msg"><div class="gmail_msg">  2 = MemoryDef(1)<br class="gmail_msg">  3 = MemoryUse(1)<br class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">Invoking createMemoryAccess followed by RAUW of 1's uses with 4 would result in:<br class="gmail_msg"></div><div class="gmail_msg"></div></div></div></div><div dir="ltr" class="gmail_msg"><div class="gmail_extra gmail_msg"><div class="gmail_quote gmail_msg"><div class="gmail_msg"><br class="gmail_msg"><div class="gmail_msg"><span class="m_-6466548616601174784m_7998958474538251886gmail- gmail_msg">  0 = MemoryDef(liveOnEntry)<br class="gmail_msg">  1 = MemoryDef(0)<br class="gmail_msg"></span></div></div></div></div></div><div dir="ltr" class="gmail_msg"><div class="gmail_extra gmail_msg"><div class="gmail_quote gmail_msg"><div class="gmail_msg"><div class="gmail_msg"><span class="m_-6466548616601174784m_7998958474538251886gmail- gmail_msg">  4 = MemoryDef(4)   ; <=======<br class="gmail_msg"></span></div>  2 = MemoryDef(4)<br class="gmail_msg">  3 = MemoryUse(4)<br class="gmail_msg"><br class="gmail_msg">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.<br class="gmail_msg"></div></div></div></div><div dir="ltr" class="gmail_msg"><div class="gmail_extra gmail_msg"><div class="gmail_quote gmail_msg"><div class="gmail_msg"> </div><blockquote class="gmail_quote gmail_msg" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr" class="gmail_msg"><div class="gmail_extra gmail_msg"><div class="gmail_quote gmail_msg"><span class="m_-6466548616601174784m_7998958474538251886gmail- gmail_msg"><blockquote class="gmail_quote gmail_msg" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">So createDefiningAccess now permits the option of updating the users.<br class="gmail_msg"></blockquote><div class="gmail_msg"><br class="gmail_msg"></div></span><div class="gmail_msg">Please, no.</div><div class="gmail_msg"><br class="gmail_msg"></div></div></div></div>
</blockquote></div></div></div></blockquote></div></div>