[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