<html><head><meta http-equiv="Content-Type" content="text/html charset=iso-8859-1"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><br><div><div>On Jul 3, 2013, at 11:20 , Eli Friedman <<a href="mailto:eli.friedman@gmail.com">eli.friedman@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div dir="ltr">On Wed, Jul 3, 2013 at 11:07 AM, Matt Arsenault <span dir="ltr"><<a href="mailto:arsenm2@gmail.com" target="_blank">arsenm2@gmail.com</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote">
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5"><br>
On Jul 3, 2013, at 8:20 , Matt Arsenault <<a href="mailto:arsenm2@gmail.com">arsenm2@gmail.com</a>> wrote:<br>
<br>
><br>
> On Jul 2, 2013, at 23:15 , Matt Arsenault <<a href="mailto:arsenm2@gmail.com">arsenm2@gmail.com</a>> wrote:<br>
><br>
>> On Jul 2, 2013, at 21:38 , Eli Friedman <<a href="mailto:eli.friedman@gmail.com">eli.friedman@gmail.com</a>> wrote:<br>
>>><br>
>>> High-level issues:<br>
>>><br>
>>> 1. The way this is written, adding a data layout string to a module can turn a valid module into an invalid module. We should consider introducing some sort of safe invariant here (either ban modules without data layouts outright, or don't allow them to use non-zero address spaces).<br>
>><br>
>> Option 2 would work. I don't know know what the use case is for not having a datalayout is, and think it should be required although changing that sounds like more effort.<br>
><br>
> Thinking about this again, I think bitcasts between all address spaces should be disallowed, even if they are the same size. If somebody still really wants to do that, ptrtoint as 1 / inttoptr as 2 still works, and the bit code is still upgraded. In the original thread about this patch, I don't understand why both the bitcode would be updated and same-sized address spaces casts would be allowed. It would be simplest to just convert all address space bitcasts.<br>
<br>
</div></div>This upgrade path doesn't work for global aliases since it expects a bitcast or getelementptr. I suppose it could be made to accept inttoptr</blockquote></div><br></div><div class="gmail_extra">Does it even make sense to have a global alias where the target isn't in the same address space? That sounds like something the verifier should just reject.</div>
<div class="gmail_extra"><br></div><div class="gmail_extra">-Eli</div></div>
</blockquote></div><br><div>I don't think so. I have no use for it. It's just the bitcast between them is currently accepted, so somebody might be using it in some perverse way. I'm fine with just ignoring it if nobody cares.</div><div><br></div></body></html>