[PATCH] Support for address space casting in order to map these on the new 'addrspacecast' IR instruction

[Michele Scandale]

On 11/29/2013 07:39 AM, John McCall wrote:
> On Nov 27, 2013, at 12:02 AM, Michele Scandale <michele.scandale at gmail.com> wrote:
>>  in origin I had the same feeling, as you can see in the first patch I proposed there was a CK_AddressSpaceCast in order to extend the semantic level to support this (initially just for C-Style casts). Being not so confident, I reduced the modification in order to just fix the code generator.
> 
> I agree that we should have at least one address-space-changing cast kind.  We should also introduce an AST assertion that other CKs not be used to change address spaces (of the immediate pointee only, of course).
> 
> I would call this an AddressSpaceBitCast to make it clear that a pointer to one address space is being converted completely non-semantically to a different address space.

The 'addrspacecast' instruction would represent a semantic change, thus it's
behavior is to not generally preserve the bit sequence. So if it's legal, the
pointee object must be the same.

> I say non-semantically because the embedded C spec includes the concept of subset address spaces: e.g. an 8-bit address space at a known offset within a larger address space.  If someone ever feels inclined to support that spec correctly, we'll want address-space conversions other than bit-casts.  It sounds like all of these would eventually turn into the same LLVM addrspacecast instruction, although potentially more than one.
> 
> The embedded C spec is not very helpful when it comes to bit-cast address space conversions: you can use a cast, but it has undefined behavior if the result doesn’t point to the same object that the operand logically did: i.e. it’s always undefined if the address spaces are non-overlapping.  I think a more reasonable set of rules to use as a basis for language design here are those for casting a pointer to an integer type: i.e. you’re still within defined behavior as long as you get back to the original type in the end and you’ve round-tripped the value successfully.
> 
> It would be natural for static_cast to only be able to apply and reverse conversions between overlapping address spaces, but for reinterpret_cast to have the full power of a C cast (w.r.t. the address space qualifier only, of course).

In order to represent the 'reinterpret_cast' as a pure bitcast the generated
code should be a pair of ptrtoint+inttoptr.

> And for the record, this is new feature work and therefore not appropriate for the release branch.  I hope that the LLVM reviewers didn’t approve the addrspacecast instruction being moved over?  That seems massively out of scope.

I'm sorry to inform you that it has been commited before the release branch.

> John.
> 

My doubts concern how and which ones of the common C and C++ casting operators
should be mapped on the addrspacecast.
F.i., in C cast operator should be fine to use addrspacecast instruction when
the source and destination pointer have different address spaces. While in C++
reinterpret_cast I'm quite sure that ptrtoint+inttoptr is the correct wait to
represent it when the source and destination pointer have different address
spaces. What about static_cast?