[PATCH] Reject bitcasts between address spaces with different sizes

[Eli Friedman]

On Wed, Jul 3, 2013 at 11:07 AM, Matt Arsenault <arsenm2 at gmail.com> wrote:

>
> On Jul 3, 2013, at 8:20 , Matt Arsenault <arsenm2 at gmail.com> wrote:
>
> >
> > On Jul 2, 2013, at 23:15 , Matt Arsenault <arsenm2 at gmail.com> wrote:
> >
> >> On Jul 2, 2013, at 21:38 , Eli Friedman <eli.friedman at gmail.com> wrote:
> >>>
> >>> High-level issues:
> >>>
> >>> 1. The way this is written, adding a data layout string to a module
> can turn a valid module into an invalid module.  We should consider
> introducing some sort of safe invariant here (either ban modules without
> data layouts outright, or don't allow them to use non-zero address spaces).
> >>
> >> Option 2 would work. I don't know know what the use case is for not
> having a datalayout is, and think it should be required although changing
> that sounds like more effort.
> >
> > Thinking about this again, I think bitcasts between all address spaces
> should be disallowed, even if they are the same size. If somebody still
> really wants to do that, ptrtoint as 1 / inttoptr as 2 still works, and the
> bit code is still upgraded. In the original thread about this patch, I
> don't understand why both the bitcode would be updated and same-sized
> address spaces casts would be allowed. It would be simplest to just convert
> all address space bitcasts.
>
> This upgrade path doesn't work for global aliases since it expects a
> bitcast or getelementptr. I suppose it could be made to accept inttoptr


Does it even make sense to have a global alias where the target isn't in
the same address space?  That sounds like something the verifier should
just reject.

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