<div dir="ltr"><div class="gmail_quote"><div dir="ltr">On Thu, Jul 14, 2016 at 8:21 PM Sanjoy Das <<a href="mailto:sanjoy@playingwithpointers.com">sanjoy@playingwithpointers.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi Chandler,<br>
<br>
Chandler Carruth wrote:<br>
 > I actually think there is a pretty clean incremental path from 2a to 3<br>
<br>
Reading the rest of what you wrote, it looks like you meant "from 2b<br>
to 3"?<br></blockquote><div><br></div><div>Doh, yes. Sorry.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> > One thing you didn't mention is that this requires a matching function<br>
 > attribute too so that we can distinguish between a call site that reads<br>
 > memory and a call site that reads memory in a way that is potentially<br>
 > unsafe.<br>
<br>
Yes, thanks for bringing this up.<br>
<br>
One interesting possibility is to not make this function attribute<br>
specific to memory at all.  Then we can use it to communicate "this<br>
function may have undefined behavior", and fearlessly hoist "readnone<br>
nounwind" functions that are not also "unsafe".<br></blockquote><div><br></div><div>This is ... an extremely interesting idea.</div><div><br></div><div>Can you start a separate RFC about this?</div><div><br></div><div>I think it is important to understand how these things interact with each other, but it sounds like they may form a very cohesive whole.</div></div></div>