<p dir="ltr"><br>
On May 17, 2016 4:50 PM, "Peter Collingbourne" <<a href="mailto:peter@pcc.me.uk">peter@pcc.me.uk</a>> wrote:<br>
><br>
> pcc added a comment.<br>
><br>
> > Should the verifier check if this the property is invalidly set?<br>
><br>
><br>
> I discussed this a little with @majnemer on IRC. I think we cannot do this because passes should be allowed to introduce benign address comparisons. One example of this is speculative comparison of vtable addresses for devirtualization (vtables are unnamed_addr in C++, but imagine some other language where they weren't). If globalopt were to mark globals local_unnamed_addr, that would cause any speculative comparison to fail to verify.<br>
><br>
> One way to solve the problem could be to teach the devirtualizer to clear the local_unnamed_addr attribute, but imagine some case where some pass that runs after the devirtualizer uncovers the comparison (for example, if a constructor is inlined into a devirtualized call site, that might cause both sides of the comparison to become constant). This means that any number of passes would need to protect against this situation.</p>
<p dir="ltr">Sounds reasonable. With the current attribute we already trust that wherever added the attribute knew what it was doing.<br>
 <br>
Cheers,<br>
Rafael</p>