<div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Mar 7, 2014 at 11:35 AM, Matt Arsenault <span dir="ltr"><<a href="mailto:arsenm2@gmail.com" target="_blank">arsenm2@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class=""><div><div>On Mar 7, 2014, at 11:18 AM, Chandler Carruth <<a href="mailto:chandlerc@gmail.com" target="_blank">chandlerc@gmail.com</a>> wrote:</div>
<br><blockquote type="cite"><div style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;line-height:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px">
1) I don't understand why we don't allow bitcasting between address spaces when they are the same size. We have the datalayout embedded in the module, we should be able to verify this, etc etc. Breaking the same-size "as if" semantics of bitcast seems a pointless limitation.</div>
<br></blockquote></div><br></div><div>Pointers with different address spaces may have different representations and could need a nontrivial transformation between them.</div></blockquote></div><br>Yes, I'm suggesting that bitcast should *not* do what addrspacecast does, but shoudl do what storing and loading the bits does.</div>
<div class="gmail_extra"><br></div><div class="gmail_extra">This might produce a garbage pointer, but garbage in, garbage out. Making it invalid IR seems like it makes things like SROA unnecessarily complex.</div></div>