[PATCH] Reject bitcasts between address spaces with different sizes

[Matt Arsenault]

On Jul 3, 2013, at 11:20 , Eli Friedman <eli.friedman at gmail.com> wrote:

> 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

I don't think so. I have no use for it. It's just the bitcast between them is currently accepted, so somebody might be using it in some perverse way. I'm fine with just ignoring it if nobody cares.

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