[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