[PATCH] Reject bitcasts between address spaces with different sizes

Matt Arsenault arsenm2 at gmail.com
Wed Jul 3 11:07:46 PDT 2013


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



More information about the llvm-commits mailing list