[PATCH] Address Space Casting

Michele Scandale michele.scandale at gmail.com
Wed Sep 4 01:15:00 PDT 2013


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 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) 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 ) 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".

Indeed I don't think that in the autoupgrade changing a ptrtoint+inttoptr to an 
address space cast is generally correct: I cannot distinguish the cases where 
that pair was intended for an address space cast or the cases where the original 
intention was to use the proper semantic of ptrtoint and inttoptr.

I think that we would need to clarify again what is needed precisely in the auto 
upgrade mechanism.

-Michele



More information about the llvm-commits mailing list