[PATCH] Address Space Casting

Eli Friedman eli.friedman at gmail.com
Wed Sep 4 13:00:56 PDT 2013


On Wed, Sep 4, 2013 at 1:15 AM, Michele Scandale <michele.scandale at gmail.com
> wrote:

> On 09/04/2013 01:01 AM, Eli Friedman wrote:
>
>> On Tue, Sep 3, 2013 at 3:01 PM, Michele Scandale <
>> michele.scandale at gmail.com
>> <mailto:michele.scandale@**gmail.com <michele.scandale at gmail.com>>>
>> wrote:
>>
>>
>>
>>     ================
>>     Comment at: lib/IR/AutoUpgrade.cpp:404
>>     @@ +403,2 @@
>>     +  return Opc;
>>     +}
>>     ----------------
>>     Eli Friedman wrote:
>>      > This isn't appropriate: this transformation changes the semantics
>> of the
>>     code.  bitcast is explicitly not equivalent to addrspacecast; it's
>>     equivalent to a ptrtoint+inttoptr pair.
>>      From what have been discussed before
>>     (http://lists.cs.uiuc.edu/**pipermail/llvmdev/2013-August/**
>> 064674.html<http://lists.cs.uiuc.edu/pipermail/llvmdev/2013-August/064674.html>)
>> seems
>>     that before bitcast was used to convert two pointers between different
>>     address spaces... That's the reason for that code....
>>
>>
>> "bitcast" has always been defined in LangRef as a no-op.  The whole
>> reason for
>> adding addrspacecast is precisely because it isn't a no-op.  They are
>> clearly
>> not equivalent.
>>
>
> 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.
>
> 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.
>
> The following part of the specification ( http://lists.cs.uiuc.edu/**
> pipermail/llvmdev/2013-August/**064674.html<http://lists.cs.uiuc.edu/pipermail/llvmdev/2013-August/064674.html>) 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".
>
> That just means that ptrtoint+inttoptr isn't equivalent to an
addrspacecast. :)

-Eli
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20130904/afe8efe7/attachment.html>


More information about the llvm-commits mailing list