<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">2017-05-08 20:51 GMT+02:00 Sanjoy Das <span dir="ltr"><<a href="mailto:sanjoy@playingwithpointers.com" target="_blank">sanjoy@playingwithpointers.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi Piotr,<br>
<span class="gmail-"><br>
On Thu, May 4, 2017 at 6:44 AM, Piotr Padlewski<br>
<<a href="mailto:piotr.padlewski@gmail.com">piotr.padlewski@gmail.com</a>> wrote:<br>
> Also, Sanjoy proposed to mark invariant.group features as experimental, so<br>
> we will not be afraid to break behavior of frontends that already use it.<br>
><br>
> Right now I am pretty sure that clang is the only one that curently uses it<br>
> (and not by default).</span><br>
<span style="font-size:12.8px">Firstly, yes, I think we should definitely make the barrier stuff</span><br style="font-size:12.8px"><span style="font-size:12.8px">experimental.  I don't think it has been ironed out enough for</span><br style="font-size:12.8px"><span style="font-size:12.8px">generally use.</span></blockquote><div>Oh right, I will post patch that will mention it in the LangRef this week and see if there will be any objections. </div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
Secondly, at this point I'm wondering if the barrier/invariant.group<br>
is the right abstraction at all.  Are there other designs you<br>
considered early on that we can revisit in the light of these issues?<br>
<span class="gmail-HOEnZb"><font color="#888888"><br>
-- Sanjoy<br></font></span></blockquote><div><br></div><div>I don't think there were any other ideas for propagation of the "invartianess" of the vptr - </div><div>@Richard or @Nick, did you have any other ideas before my internship?</div><div><br></div><div><br></div><div>I am open to hear any other ideas for the model - even if they would be not checked it might be a good inspiration.</div><div>Right now the only problem with the current model for devirtualization (that we have seen) is the propagation</div><div>of the pointers from comparision. It is also the problem that we knew almost from the beginning.</div><div>@Sanjoy, maybe you have some ideas how the semantics of the !invariant.groups with propagation</div><div>of the pointers could be specified in a way that it would not brake the testcases?</div><div><br></div><div><br></div><div>Piotr  </div></div><br></div></div>