<div dir="ltr">On Wed, Sep 4, 2013 at 1:15 AM, Michele Scandale <span dir="ltr"><<a href="mailto:michele.scandale@gmail.com" target="_blank">michele.scandale@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="im">On 09/04/2013 01:01 AM, Eli Friedman wrote:<br>
</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">
On Tue, Sep 3, 2013 at 3:01 PM, Michele Scandale <<a href="mailto:michele.scandale@gmail.com" target="_blank">michele.scandale@gmail.com</a><br></div><div><div class="h5">
<mailto:<a href="mailto:michele.scandale@gmail.com" target="_blank">michele.scandale@<u></u>gmail.com</a>>> wrote:<br>
<br>
<br>
<br>
    ================<br>
    Comment at: lib/IR/AutoUpgrade.cpp:404<br>
    @@ +403,2 @@<br>
    +  return Opc;<br>
    +}<br>
    ----------------<br>
    Eli Friedman wrote:<br>
     > This isn't appropriate: this transformation changes the semantics of the<br>
    code.  bitcast is explicitly not equivalent to addrspacecast; it's<br>
    equivalent to a ptrtoint+inttoptr pair.<br>
     From what have been discussed before<br>
    (<a href="http://lists.cs.uiuc.edu/pipermail/llvmdev/2013-August/064674.html" target="_blank">http://lists.cs.uiuc.edu/<u></u>pipermail/llvmdev/2013-August/<u></u>064674.html</a>) seems<br>
    that before bitcast was used to convert two pointers between different<br>
    address spaces... That's the reason for that code....<br>
<br>
<br>
"bitcast" has always been defined in LangRef as a no-op.  The whole reason for<br>
adding addrspacecast is precisely because it isn't a no-op.  They are clearly<br>
not equivalent.<br>
</div></div></blockquote>
<br>
If previously a bitcast was generated because of the no-op semantic (assuming that was the correct semantic for the specific target) then also with the addrspacebitcast that semantic is kept: in fact the addrspacecast can be a no-op for a given address space pair if the target allow that. Without any target information the conservative behavior is that an address space cast changes the value and the size.<br>

<br>
The addrspacecast add the support for a generic address casting (potentially a value and size change). Before this, bitcast was the noop address space cast and ptrtoint+inttoptr was proposed as the way to handle size change and value change with truncation/zero extension.<br>

<br>
The following part of the specification ( <a href="http://lists.cs.uiuc.edu/pipermail/llvmdev/2013-August/064674.html" target="_blank">http://lists.cs.uiuc.edu/<u></u>pipermail/llvmdev/2013-August/<u></u>064674.html</a> ) is still missing because I do not understand its need: "The semantics of inttoptr of inttoptr where the source and destination are in different address spaces are target-dependent and may be undefined for any given conversion".<br>
<br></blockquote><div>That just means that ptrtoint+inttoptr isn't equivalent to an addrspacecast. :)<br><br>-Eli <br></div></div></div></div>