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

[Richard Smith]

I'm not especially happy with using CK_BitCast for something other than a
bit cast -- that seems basically wrong to me. There's also a language
design question here. If I have two pointers to different address spaces
that happen to be the same bit-width, and I write:

  typedef int *p1 __attribute__((address_space(1)));
  typedef int *p2 __attribute__((address_space(2)));

  p2 f(p1 p) { return static_cast<p2>(p1); }
  p2 g(p1 p) { return reinterpret_cast<p2>(p1); }

... I would probably expect 'f' to return me a pointer to the same memory
(with potentially a different value) if that's possible, and to be an error
if it's not possible. I would probably expect 'g' to return me a bitcasted
pointer. That too suggests that we can't steal CK_BitCast to mean "do
something other than a bitcast".


On Tue, Nov 26, 2013 at 8:34 AM, David Tweed <david.tweed at gmail.com> wrote:

>
>   Regarding your response, that seems reasonable. I guess it's up to the
> "address spaces for security" guys to validate clang's semantic checking
> with respect to their needs. (I'd been thinking about devious things like
> somehow creating an one of those pointer types and using it to put the
> "evasion of the security sandboxing" into the generated LLVM IR, but that's
> for the more security knowledgeable to deal with.)
>
> http://llvm-reviews.chandlerc.com/D2241
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20131126/9993b63b/attachment.html>